Compilation failure - Version: 0.9.2

[RGeorgy]

Followed the instruction and run setup ... finally my web request "http://raspberrypi/osm" only gave me a pink screen when changing to local database and no map!

Attached file shows the system messages. The first Exception has to do that I run the script already once. I solved this. But I could not resolve the following issues:

/usr/share/apr-1.0/build/libtool --mode=compile --tag=disable-static arm-linux-gnueabihf-gcc -prefer-pic -pipe -g -O2 -fdebug-prefix-map=/build/apache2-bjCht8/apache2-2.4.25=. -fstack-protector-strong -Wformat -Werror=format-security -DBUILD_DATETIME='"2018-11-03T18:46:19"' -Wdate-time -D_FORTIFY_SOURCE=2 -DLINUX -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -pthread -I/usr/include/apache2 -I/usr/include/apr-1.0 -I/usr/include/apr-1.0 -I/usr/include -I./includes -c -o ./src/mod_tile.lo ./src/mod_tile.c && touch ./src/mod_tile.slo libtool: compile: arm-linux-gnueabihf-gcc -pipe -g -O2 -fdebug-prefix-map=/build/apache2-bjCht8/apache2-2.4.25=. -fstack-protector-strong -Wformat -Werror=format-security -DBUILD_DATETIME=\"2018-11-03T18:46:19\" -Wdate-time -D_FORTIFY_SOURCE=2 -DLINUX -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -pthread -I/usr/include/apache2 -I/usr/include/apr-1.0 -I/usr/include/apr-1.0 -I/usr/include -I./includes -c ./src/mod_tile.c -fPIC -DPIC -o ./src/.libs/mod_tile.o ./src/mod_tile.c: In function ‘add_expiry’: ./src/mod_tile.c:504:44: warning: format ‘%lld’ expects argument of type ‘long long int’, but argument 3 has type ‘long int’ [-Wformat=] apr_psprintf(r->pool, "max-age=%" APR_TIME_T_FMT, ^~~

and also errors like

./src/mod_tile.c:504:44: warning: format ‘%lld’ expects argument of type ‘long long int’, but argument 3 has type ‘long int’ [-Wformat=] apr_psprintf(r->pool, "max-age=%" APR_TIME_T_FMT,

Any help is kindly appreciated! Merry Christmas! message.txt

[sbodmer]

Hi, It seems you problem is linked to the mod_tile apache module (and not with my script) compilation, so I think you should go to https://github.com/openstreetmap/mod_tile to report your problem.

As an alternative (without need for compilation), try the tilestache version of my script, to check if the rest (database) works on the pi.

Merry Christmas too.

[RGeorgy]

Thank you so much for your comment. I think you are correct, but how did you conclude this. If I want to report a problem, I need to explain the what the issue is. I cannot just say - it does not work. Sorry for bothering you with this. Best regards!

[sbodmer]

Hi RGeorgy,

To check for errors, simply git clone the mod_tile project, then try to build it on your raspberry, you will certainly see some compilation error/warnings, simply report them on the project site, it should be enough, because it means that mod_tile is not compatible with arm cpus and the author will know how to fix it. If the compilation does not return errors (it compiles fines), then it will more harder to find the problem and you have to investigate yourself the cause of mod_tile not working correctly.

Bye

[sbodmer]

Hi RGeorgy

I tried the script on my raspberry pi 3 and I got compilation warnings and there were no tiles displayed (pink not found tile), so I can confirm the problem. You have to check with mod_tile project to find out if the compilation warnings are justified for arm architecture and the cause of the problem.

Bye

[RGeorgy]

Just to finalise this! I tested it again from scratch using Raspian 2018-11-13_raspbian-stretch-full. It was working, although some warning messages etc. appeared I did not run the recommeded software installation of "stretch" and just startet the batch file. Just a quick notice for all who wanted to know - slippymap.html on a Raspberry Pi 3b+ for a small region (Germany - Saarland) takes ages to compute. Wonder if it is just the slippymap algo or it really takes that long.

[sbodmer]

Hi RGeorgy

Thanks for you follow-up. For your information, I prefer to install a minimal version of debian (raspbian lite) when I install a tile server. The slowness is not the cause of slippymap.html (as this code is executed on the client [browser] side), the pi postgresql performance for tile serving seems to be to low to be viable...

Happy new year.