[Announce] Native offline maps: OSM Scout Server - Page 49 - maemo.org

rinigus | # 481 | 2018-05-18, 19:16 | Report

Originally Posted by pichlo View Post

I second that. I was just trying to send you a donation but you do not make it exactly easy

Thanks for trying! I'll look into it a bit later...

As for OSM Scout Server, I am working on updating libpostal to 1.0 version. This will bring changes in Address parser database format leading to incompatibilities of the future maps with the current server version. I'll try to warn in advance, so you could plan map downloads and server updates.

The Following 8 Users Say Thank You to rinigus For This Useful Post:
Feathers McGraw, Fellfrosch, imaginaryenemy, juiceme, klinglerware, peterleinchen, pichlo, seiichiro0185

rinigus | # 482 | 2018-05-25, 08:06 | Report

As mentioned above, I am working on updating libpostal to 1.0. While API was adopted fast, there were few issues that I had to hack around. The main is https://github.com/openvenues/libpostal/issues/351 , for which I seem to have workaround (at least the planet was imported).

I'll be testing it over the next few days. The tests over the last week (even before workaround) were promising. If all goes fine, I'll update the software and the maps via corresponding distribution channels. However, note that its rather large change and those who have to rely on the server in the next couple of weeks, please check for the feedback of the ones who updated first. Also, if you wish to delay the update, please get all the maps before the update will hit the servers. Otherwise, you'll be unable to do that later.

The Following 8 Users Say Thank You to rinigus For This Useful Post:
Amboss, Feathers McGraw, jayki, juiceme, klinglerware, MartinK, peterleinchen, seiichiro0185

rinigus | # 483 | 2018-05-27, 04:06 | Report

New version is out: 1.6.0

This is a major upgrade and, due to the upgrade of libpostal API, the address parsing part of the maps is incompatible with the earlier versions. After upgrade, go to Map Manager, click "Check for updates" and proceed as usual. Below, is the description of what's new.

This version is the first one supporting QtQuick Controls GUI. So, it opens full GUI for Linux desktops. It could also simplify porting to Nemo, Ubuntu Touch, Plasma Mobile, if any porting is needed at all.

Upgrade of libpostal brings us a large work done by libpostal author in 2017. I would like to encourage you to test performance of the search and check whether your query was parsed correctly. From disk storage requirements side, the new libpostal doesn't use language parser dataset anymore which should reduce storage requirements by ~500MB on global dataset. Country datasets have changed as well, but that could be larger or smaller than before, depending on the country.

Geocoder now sorts the results somewhat differently to promote Glasgow (city) in front of the pub with the same name. This is done by preferring results with smaller number of admin levels (so Malmö kommun is preferred to Malmö city) and, for the same admin level results, with the shorter name.

Valhalla packaging changes were already in use earlier, but now the scripts are part of the release. I am also not showing country selection when its not needed in the main screen (its used only if geocoder is limited to one country or libosmscout is in use).

The translations have been updated and Dutch (BE) added to the list by @pljmn. Thanks for all the translators!

Current libpostal SFOS adaptation uses one reversed commit. Such adaptation allowed me to import the planet, but it may have some side effects. So, please tell if the server is killed for one reason or another. The corresponding issue has been opened at libpostal repository, but its not properly resolved yet.

Finally, as a simpler version, I added bitcoin donation link. Please don't ask for paypal, I don't want to engage with it at the moment. Bitcoin, as liberapay, gives you the list of transactions. So, all donations are transparent in terms of time and amounts.

New updated libpostal and geocoder-nlp datasets are available, enjoy the release.

The Following 18 Users Say Thank You to rinigus For This Useful Post:
acrux, Amboss, borghal, carmenluci, DrYak, Feathers McGraw, juiceme, karlos devel, klinglerware, Mara, MartinK, nthn, olf, PamNor, peterleinchen, pichlo, Saturn, seiichiro0185

MartinK | # 484 | 2018-05-28, 20:37 | Report

Originally Posted by rinigus View Post

New version is out: 1.6.0
This version is the first one supporting QtQuick Controls GUI. So, it opens full GUI for Linux desktops. It could also simplify porting to Nemo, Ubuntu Touch, Plasma Mobile, if any porting is needed at all.

Nice!

On a related note, I finally managed to have some progress in my Fedora packaging efforts:

prime_server
- PR: https://github.com/rinigus/pkg-prime_server/pull/1 (already merged, thanks!

)
- builds fine in Fedora COPR
- opened an upstream issue to clarify licensing: https://github.com/kevinkreiser/prime_server/issues/70

valhalla
- PR: https://github.com/rinigus/pkg-valhalla/pull/1
- fails during build in COPR due to some weird protocol buffer errors, details are in the pull request

What OSM Scout Server dependencies would you recommend next ? Looking at the OSM Scout Server spec file:

already available
- marise (0.2.4) is already packaged
- mapnik (3.0.19) is already packaged
- libmicrohttpd (0.9.59) is already packaged
- tokyocabinet (1.4.48) is already packaged

missing in Fedora
- libosmscout is not yet packaged
- libpostal is not yet packaged

The Following 10 Users Say Thank You to MartinK For This Useful Post:
Amboss, Feathers McGraw, imaginaryenemy, juiceme, klinglerware, lal, olf, peterleinchen, rinigus, velox

rinigus | # 485 | 2018-05-29, 06:38 | Report

Originally Posted by MartinK View Post

Nice!

On a related note, I finally managed to have some progress in my Fedora packaging efforts:

prime_server
- PR: https://github.com/rinigus/pkg-prime_server/pull/1 (already merged, thanks!

)
- builds fine in Fedora COPR
- opened an upstream issue to clarify licensing: https://github.com/kevinkreiser/prime_server/issues/70

valhalla
- PR: https://github.com/rinigus/pkg-valhalla/pull/1
- fails during build in COPR due to some weird protocol buffer errors, details are in the pull request

What OSM Scout Server dependencies would you recommend next ? Looking at the OSM Scout Server spec file:

already available
- marise (0.2.4) is already packaged
- mapnik (3.0.19) is already packaged
- libmicrohttpd (0.9.59) is already packaged
- tokyocabinet (1.4.48) is already packaged

missing in Fedora
- libosmscout is not yet packaged
- libpostal is not yet packaged

Marisa, libmicrohttpd, tokyocabinet should be OK

Mapnik: Mapnik in 3.0.x line still doesn't include TWKB support for SQLite databases. The corresponding PR has been merged upstream (https://github.com/mapnik/mapnik/pull/3660) and I am currently applying patch while building Mapnik for SFOS (https://github.com/rinigus/pkg-mapni...nik.twkb.patch). Without it, Mapnik maps were 2x larger, if memory serves me right. Hence, all distributed maps use this format and vanilla 3.0.x Mapnik will be unable to render them. Se, we'll need either to convince Fedora packagers to add this patch or package it separately and link statically to the server.

libosmscout: I am using rather old version of it, see https://github.com/rinigus/libosmscout/tree/sailfish . Newer versions have somewhat different API and I decided not to get involved into keeping it up to date. So far, nobody volunteered to keep this part of code in sync with the latest libosmscout releases. We can also skip libosmscout for this packaging round and compile the server without it (there is a disable option in qt pro file). The release that I use is https://github.com/rinigus/libosmsco...git.20170521-1

libpostal: Current libpostal has a bug that can be triggered by searching for "Хозтовары" (issue https://github.com/openvenues/libpostal/issues/351). Please use https://github.com/rinigus/pkg-libpostal with devel branch (https://build.merproject.org/package...ice?expand=1); loads https://github.com/rinigus/libpostal...nsion_fail_fix branch. Usually, libpostal developer is fast in responding to issues. For some reason, he hasn't been that active lately. But I am sure it will get fixed and we can later switch to the upstream branch.

So, while lots of functionality is provided by packages, there is still quite some work that has to be done behind the scenes to make it all work in practice

Thanks for working on it, looking forward to see the server in mainstream Linux.

The Following 7 Users Say Thank You to rinigus For This Useful Post:
Amboss, Feathers McGraw, imaginaryenemy, juiceme, olf, peterleinchen, velox

DrYak | # 486 | 2018-05-29, 09:52 | Report

Big Kudos to you guys !

The Following 8 Users Say Thank You to DrYak For This Useful Post:
Amboss, Feathers McGraw, juiceme, lal, olf, peterleinchen, pichlo, rinigus

MartinK | # 487 | 2018-06-02, 11:39 | Report

Originally Posted by rinigus View Post

Marisa, libmicrohttpd, tokyocabinet should be OK

Mapnik: Mapnik in 3.0.x line still doesn't include TWKB support for SQLite databases. The corresponding PR has been merged upstream (https://github.com/mapnik/mapnik/pull/3660) and I am currently applying patch while building Mapnik for SFOS (https://github.com/rinigus/pkg-mapni...nik.twkb.patch). Without it, Mapnik maps were 2x larger, if memory serves me right. Hence, all distributed maps use this format and vanilla 3.0.x Mapnik will be unable to render them. Se, we'll need either to convince Fedora packagers to add this patch or package it separately and link statically to the server.

Oh, so the patch is already upstream, just not yet in a released version of Mapnik? For now I've just built the Fedora Mapnik package with the patch on top in COPR:
https://copr.fedorainfracloud.org/co.../build/761846/

Then once we are far enough to submit OSM Scout Server for package review (so that it can go the the official Fedora repos) we can either ask the Mapnik maintainers to include the patch or possibly a new upstream version including it has been released (and the Mapnik maintainers seem to track upstream releases pretty closely).

Originally Posted by rinigus View Post

libosmscout: I am using rather old version of it, see https://github.com/rinigus/libosmscout/tree/sailfish . Newer versions have somewhat different API and I decided not to get involved into keeping it up to date. So far, nobody volunteered to keep this part of code in sync with the latest libosmscout releases. We can also skip libosmscout for this packaging round and compile the server without it (there is a disable option in qt pro file). The release that I use is https://github.com/rinigus/libosmsco...git.20170521-1

Is there some functionality libosmscout provides that is not covered by other libraries (Valhalla/libpostal/Mapnik/etc.) ? I think we can indeed skip libosmscout for the initial packaging round, as even if it builds fine in COPR, it would be weird to submit an old version of libosmscout for package review if we know OSM Scout Server will not work with a new version if it ever gets updated.

Originally Posted by rinigus View Post

libpostal: Current libpostal has a bug that can be triggered by searching for "Хозтовары" (issue https://github.com/openvenues/libpostal/issues/351). Please use https://github.com/rinigus/pkg-libpostal with devel branch (https://build.merproject.org/package...ice?expand=1); loads https://github.com/rinigus/libpostal...nsion_fail_fix branch. Usually, libpostal developer is fast in responding to issues. For some reason, he hasn't been that active lately. But I am sure it will get fixed and we can later switch to the upstream branch.

I've tried to build libpostal yesterday and while the packing & the software itself (a C library with few depndencies) looks fairly simple, the build failed with some rather weird errors:

Code:

/bin/sh ../libtool  --tag=CC   --mode=link gcc -Wfloat-equal -Wpointer-arith -std=gnu99 -DLIBPOSTAL_DATA_DIR='"/usr/local/libpostal/data/libpostal"' -g -O3 -Wfloat-equal -Wpointer-arith -std=gnu99 -DLIBPOSTAL_DATA_DIR='"/usr/local/libpostal/data/libpostal"' -g  -Wl,-z,relro  -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -L/usr/local/lib -o test_libpostal test_libpostal-test.o test_libpostal-test_expand.o test_libpostal-test_parser.o test_libpostal-test_transliterate.o test_libpostal-test_numex.o test_libpostal-test_trie.o test_libpostal-test_string_utils.o test_libpostal-test_crf_context.o ../src/libpostal.la  -lm 
libtool: link: gcc -Wfloat-equal -Wpointer-arith -std=gnu99 -DLIBPOSTAL_DATA_DIR=\"/usr/local/libpostal/data/libpostal\" -g -O3 -Wfloat-equal -Wpointer-arith -std=gnu99 -DLIBPOSTAL_DATA_DIR=\"/usr/local/libpostal/data/libpostal\" -g -Wl,-z -Wl,relro -Wl,-z -Wl,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -o .libs/test_libpostal test_libpostal-test.o test_libpostal-test_expand.o test_libpostal-test_parser.o test_libpostal-test_transliterate.o test_libpostal-test_numex.o test_libpostal-test_trie.o test_libpostal-test_string_utils.o test_libpostal-test_crf_context.o  -L/usr/local/lib ../src/.libs/libpostal.so -lstdc++ -lm
/usr/bin/ld: test_libpostal-test.o: relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/ld: test_libpostal-test_expand.o: relocation R_X86_64_32 against `.rodata.str1.8' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/ld: test_libpostal-test_parser.o: relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/ld: test_libpostal-test_transliterate.o: relocation R_X86_64_32 against symbol `greatest_type_info_string' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/ld: test_libpostal-test_numex.o: relocation R_X86_64_32 against symbol `greatest_type_info_string' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/ld: test_libpostal-test_trie.o: relocation R_X86_64_32S against `.rodata.str1.1' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/ld: test_libpostal-test_string_utils.o: relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/ld: test_libpostal-test_crf_context.o: relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:575: test_libpostal] Error 1
make[2]: Leaving directory '/builddir/build/BUILD/libpostal-1.0.0/test'
make[1]: *** [Makefile:453: all-recursive] Error 1
make[1]: Leaving directory '/builddir/build/BUILD/libpostal-1.0.0'
make: *** [Makefile:362: all] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.TOmV84 (%build)

Full log: https://copr-be.cloud.fedoraproject....ilder-live.log

The spec file used: https://github.com/M4rtinK/pkg-libpo...libpostal.spec

Failed build in COPR: https://copr.fedorainfracloud.org/co.../build/761920/

Googling for "Nonrepresentable section on output" I found some hints that it might be related to PIE/PIC and linking. Any ideas/pointers what to try to fix the build ? Thanks in advance!

Originally Posted by rinigus View Post

So, while lots of functionality is provided by packages, there is still quite some work that has to be done behind the scenes to make it all work in practice

Thanks for working on it, looking forward to see the server in mainstream Linux.

It's a important project to which I don't know about any alternatives - so it should also be as widely available as possible, even if it requires some work.

The Following 2 Users Say Thank You to MartinK For This Useful Post:
Amboss, juiceme

rinigus | # 488 | 2018-06-02, 12:52 | Report

Originally Posted by MartinK View Post

Oh, so the patch is already upstream, just not yet in a released version of Mapnik? For now I've just built the Fedora Mapnik package with the patch on top in COPR:
https://copr.fedorainfracloud.org/co.../build/761846/

Then once we are far enough to submit OSM Scout Server for package review (so that it can go the the official Fedora repos) we can either ask the Mapnik maintainers to include the patch or possibly a new upstream version including it has been released (and the Mapnik maintainers seem to track upstream releases pretty closely).

Its in the master branch for a year, I think. However, that's for upcoming 3.1 series and they don't seem to include it into 3.0 versions.

Originally Posted by MartinK View Post

Is there some functionality libosmscout provides that is not covered by other libraries (Valhalla/libpostal/Mapnik/etc.) ? I think we can indeed skip libosmscout for the initial packaging round, as even if it builds fine in COPR, it would be weird to submit an old version of libosmscout for package review if we know OSM Scout Server will not work with a new version if it ever gets updated.

No, there is none. In this context, it just allows to use smaller databases. And I agree, it will be weird to submit old libosmscout version.

Originally Posted by MartinK View Post

I've tried to build libpostal yesterday and while the packing & the software itself (a C library with few depndencies) looks fairly simple, the build failed with some rather weird errors:

Code:

/bin/sh ../libtool  --tag=CC   --mode=link gcc -Wfloat-equal -Wpointer-arith -std=gnu99 -DLIBPOSTAL_DATA_DIR='"/usr/local/libpostal/data/libpostal"' -g -O3 -Wfloat-equal -Wpointer-arith -std=gnu99 -DLIBPOSTAL_DATA_DIR='"/usr/local/libpostal/data/libpostal"' -g  -Wl,-z,relro  -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -L/usr/local/lib -o test_libpostal test_libpostal-test.o test_libpostal-test_expand.o test_libpostal-test_parser.o test_libpostal-test_transliterate.o test_libpostal-test_numex.o test_libpostal-test_trie.o test_libpostal-test_string_utils.o test_libpostal-test_crf_context.o ../src/libpostal.la  -lm 
libtool: link: gcc -Wfloat-equal -Wpointer-arith -std=gnu99 -DLIBPOSTAL_DATA_DIR=\"/usr/local/libpostal/data/libpostal\" -g -O3 -Wfloat-equal -Wpointer-arith -std=gnu99 -DLIBPOSTAL_DATA_DIR=\"/usr/local/libpostal/data/libpostal\" -g -Wl,-z -Wl,relro -Wl,-z -Wl,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -o .libs/test_libpostal test_libpostal-test.o test_libpostal-test_expand.o test_libpostal-test_parser.o test_libpostal-test_transliterate.o test_libpostal-test_numex.o test_libpostal-test_trie.o test_libpostal-test_string_utils.o test_libpostal-test_crf_context.o  -L/usr/local/lib ../src/.libs/libpostal.so -lstdc++ -lm
/usr/bin/ld: test_libpostal-test.o: relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/ld: test_libpostal-test_expand.o: relocation R_X86_64_32 against `.rodata.str1.8' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/ld: test_libpostal-test_parser.o: relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/ld: test_libpostal-test_transliterate.o: relocation R_X86_64_32 against symbol `greatest_type_info_string' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/ld: test_libpostal-test_numex.o: relocation R_X86_64_32 against symbol `greatest_type_info_string' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/ld: test_libpostal-test_trie.o: relocation R_X86_64_32S against `.rodata.str1.1' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/ld: test_libpostal-test_string_utils.o: relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/ld: test_libpostal-test_crf_context.o: relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:575: test_libpostal] Error 1
make[2]: Leaving directory '/builddir/build/BUILD/libpostal-1.0.0/test'
make[1]: *** [Makefile:453: all-recursive] Error 1
make[1]: Leaving directory '/builddir/build/BUILD/libpostal-1.0.0'
make: *** [Makefile:362: all] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.TOmV84 (%build)

Full log: https://copr-be.cloud.fedoraproject....ilder-live.log

The spec file used: https://github.com/M4rtinK/pkg-libpo...libpostal.spec

Failed build in COPR: https://copr.fedorainfracloud.org/co.../build/761920/

Googling for "Nonrepresentable section on output" I found some hints that it might be related to PIE/PIC and linking. Any ideas/pointers what to try to fix the build ? Thanks in advance!

Try to drop https://github.com/M4rtinK/pkg-libpo...ostal.spec#L33

Code:

CFLAGS="$CFLAGS -fPIC -lstdc++"
CXXFLAGS="$CXXFLAGS -fPIC"

I had to use it for SFOS packaging, but it shouldn't be needed for you.

Originally Posted by MartinK View Post

It's a important project to which I don't know about any alternatives - so it should also be as widely available as possible, even if it requires some work.

Well, there are servers around (valhalla, tile servers, and geocoders) that are surely better in many aspects. Probably, the main advantage is that all map data is packaged and available online. It helps that you "just" need to install only one server as well [which means that the hard part of install is done by packagers].

The Following 4 Users Say Thank You to rinigus For This Useful Post:
Amboss, Feathers McGraw, juiceme, mosen

MartinK | # 489 | 2018-06-02, 23:15 | Report

Originally Posted by rinigus View Post

Try to drop https://github.com/M4rtinK/pkg-libpo...ostal.spec#L33

Code:

CFLAGS="$CFLAGS -fPIC -lstdc++"
CXXFLAGS="$CXXFLAGS -fPIC"

I had to use it for SFOS packaging, but it shouldn't be needed for you.

Tried that, still the same errors (at least AFAICT):

Code:

/bin/sh ../libtool  --tag=CC   --mode=link gcc -Wfloat-equal -Wpointer-arith -std=gnu99 -DLIBPOSTAL_DATA_DIR='"/usr/local/libpostal/data/libpostal"' -g -O3 -Wfloat-equal -Wpointer-arith -std=gnu99 -DLIBPOSTAL_DATA_DIR='"/usr/local/libpostal/data/libpostal"' -g  -Wl,-z,relro  -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -L/usr/local/lib -o test_libpostal test_libpostal-test.o test_libpostal-test_expand.o test_libpostal-test_parser.o test_libpostal-test_transliterate.o test_libpostal-test_numex.o test_libpostal-test_trie.o test_libpostal-test_string_utils.o test_libpostal-test_crf_context.o ../src/libpostal.la  -lm 
libtool: link: gcc -Wfloat-equal -Wpointer-arith -std=gnu99 -DLIBPOSTAL_DATA_DIR=\"/usr/local/libpostal/data/libpostal\" -g -O3 -Wfloat-equal -Wpointer-arith -std=gnu99 -DLIBPOSTAL_DATA_DIR=\"/usr/local/libpostal/data/libpostal\" -g -Wl,-z -Wl,relro -Wl,-z -Wl,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -o .libs/test_libpostal test_libpostal-test.o test_libpostal-test_expand.o test_libpostal-test_parser.o test_libpostal-test_transliterate.o test_libpostal-test_numex.o test_libpostal-test_trie.o test_libpostal-test_string_utils.o test_libpostal-test_crf_context.o  -L/usr/local/lib ../src/.libs/libpostal.so -lm
/usr/bin/ld: test_libpostal-test.o: relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/ld: test_libpostal-test_expand.o: relocation R_X86_64_32 against `.rodata.str1.8' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/ld: test_libpostal-test_parser.o: relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/ld: test_libpostal-test_transliterate.o: relocation R_X86_64_32 against symbol `greatest_type_info_string' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/ld: test_libpostal-test_numex.o: relocation R_X86_64_32 against symbol `greatest_type_info_string' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/ld: test_libpostal-test_trie.o: relocation R_X86_64_32S against `.rodata.str1.1' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/ld: test_libpostal-test_string_utils.o: relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/ld: test_libpostal-test_crf_context.o: relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:575: test_libpostal] Error 1
make[2]: Leaving directory '/builddir/build/BUILD/libpostal-1.0.0/test'
make[1]: *** [Makefile:453: all-recursive] Error 1
make[1]: Leaving directory '/builddir/build/BUILD/libpostal-1.0.0'
make: *** [Makefile:362: all] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.NmocgJ (%build)

Full log: https://copr-be.cloud.fedoraproject....ilder-live.log

Link to the failed build: https://copr-be.cloud.fedoraproject....ilder-live.log

Spec file diff from previous attempt: http://copr-dist-git.fedorainfraclou...7c50aef7480688

Googling for "relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE object; recompile with -fPIC" uncovered some discussion about cases in other programs when trying to link relocatable and non-relocatable code together, so I wonder if we are seeing something like that as well. Looking at the test subfolder where this is happening, it seems to have some custom flags defined here:
https://github.com/openvenues/libpos...st/Makefile.am
So maybe it compiles the testing code wrong or something like that ?
Also I wonder if the tests could just be disabled, but that feels like a hack.

Originally Posted by rinigus View Post

Well, there are servers around (valhalla, tile servers, and geocoders) that are surely better in many aspects. Probably, the main advantage is that all map data is packaged and available online. It helps that you "just" need to install only one server as well [which means that the hard part of install is done by packagers].

Yes, that's what I think OSM Scout Server is best in the world at - making all the power of the existing open geodata & libraries seamlessly available both to application developers (language independent & well documented common API) and users (super easy offline data downloading & updates + data sharing with all apps using the OSM Scout Server API).

I don't think any existing solution can come close to this - otherwise developers would have to handle every lib themselves (compilation/packaging/bundling) & library APIs are often limited (C/C++ only, API that requires a heavy server software to run, etc.), not to mention all the hassles with offline data management that would have to be solved more or less separately for every application.

From the user side, there is super easy & unified offline data management & all the nice features made possibly by the easily accessible APIs.

The Following 6 Users Say Thank You to MartinK For This Useful Post:
Amboss, Feathers McGraw, juiceme, olf, peterleinchen, rinigus

rinigus | # 490 | 2018-06-03, 05:27 | Report

@MartinK, it builds static and shared versions of the library. I would suggest to add

Code:

--disable-static

to configure options and try again. Since static lib is built after the shared one, it may got confused and linked tests to the static libs.

Does it build on your PC?

The Following 5 Users Say Thank You to rinigus For This Useful Post:
Amboss, Feathers McGraw, juiceme, olf, peterleinchen