Active Topics
-
Maemo repository (5)
to Community by dredlok706 - 23 hrs, 20 mins ago -
Re-commissioning N9 in 2018 (127)
to MeeGo / Harmattan by smatkovi - 1 day, 1 hr ago -
Porting apps to Leste (41)
to Maemo 7 / Leste by Arno_11 - 1 day, 19 hrs ago -
List of well performing apps on Leste (33)
to Maemo 7 / Leste by teroyk - 2 days, 3 hrs ago -
N900 is not recognizable on any of my devices (windows 10,7, xp) What can I do? (1)
to Nokia N900 by nieldk - 3 days, 7 hrs ago -
Error after installing Leste on sdcard (13)
to Maemo 7 / Leste by Maemish - 6 days, 11 hrs ago -
TLS 1.2 for N9 is ready (29)
to MeeGo / Harmattan by smatkovi - 6 days, 19 hrs ago - more...
| The Following 8 Users Say Thank You to rinigus For This Useful Post: | ||
|
2018-05-25
, 08:06
|
|
Posts: 1,414 |
Thanked: 7,547 times |
Joined on Aug 2016
@ Estonia
|
#482
|
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.
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: | ||
|
|
2018-05-27
, 04:06
|
|
Posts: 1,414 |
Thanked: 7,547 times |
Joined on Aug 2016
@ Estonia
|
#483
|
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.
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: | ||
|
|
2018-05-28
, 20:37
|
|
Posts: 1,548 |
Thanked: 7,510 times |
Joined on Apr 2010
@ Czech Republic
|
#484
|
Originally Posted by rinigus
Nice!
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.
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
__________________
modRana: a flexible GPS navigation system
Mieru: a flexible manga and comic book reader
Universal Components - a solution for native looking yet component set independent QML appliactions (QtQuick Controls 2 & Silica supported as backends)
modRana: a flexible GPS navigation system
Mieru: a flexible manga and comic book reader
Universal Components - a solution for native looking yet component set independent QML appliactions (QtQuick Controls 2 & Silica supported as backends)
| The Following 10 Users Say Thank You to MartinK For This Useful Post: | ||
|
|
2018-05-29
, 06:38
|
|
Posts: 1,414 |
Thanked: 7,547 times |
Joined on Aug 2016
@ Estonia
|
#485
|
Originally Posted by MartinK
Marisa, libmicrohttpd, tokyocabinet should be OK
Nice!
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
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: | ||
|
|
2018-05-29
, 09:52
|
|
Posts: 248 |
Thanked: 1,142 times |
Joined on Dec 2014
@ Earth
|
#486
|
Big Kudos to you guys !
| The Following 8 Users Say Thank You to DrYak For This Useful Post: | ||
|
|
2018-06-02
, 11:39
|
|
Posts: 1,548 |
Thanked: 7,510 times |
Joined on Apr 2010
@ Czech Republic
|
#487
|
Originally Posted by rinigus
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:
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.
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
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.
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
Originally Posted by rinigus
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:
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.
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)
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
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.
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.
__________________
modRana: a flexible GPS navigation system
Mieru: a flexible manga and comic book reader
Universal Components - a solution for native looking yet component set independent QML appliactions (QtQuick Controls 2 & Silica supported as backends)
modRana: a flexible GPS navigation system
Mieru: a flexible manga and comic book reader
Universal Components - a solution for native looking yet component set independent QML appliactions (QtQuick Controls 2 & Silica supported as backends)
|
|
2018-06-02
, 12:52
|
|
Posts: 1,414 |
Thanked: 7,547 times |
Joined on Aug 2016
@ Estonia
|
#488
|
Originally Posted by MartinK
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.
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 MartinK
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.
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 MartinK
Try to drop https://github.com/M4rtinK/pkg-libpo...ostal.spec#L33
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:
Full log: https://copr-be.cloud.fedoraproject....ilder-live.logCode:/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)
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!
Code:
CFLAGS="$CFLAGS -fPIC -lstdc++" CXXFLAGS="$CXXFLAGS -fPIC"
Originally Posted by MartinK
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].
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 4 Users Say Thank You to rinigus For This Useful Post: | ||
|
|
2018-06-02
, 23:15
|
|
Posts: 1,548 |
Thanked: 7,510 times |
Joined on Apr 2010
@ Czech Republic
|
#489
|
Originally Posted by rinigus
Tried that, still the same errors (at least AFAICT):
Try to drop https://github.com/M4rtinK/pkg-libpo...ostal.spec#L33
I had to use it for SFOS packaging, but it shouldn't be needed for you.Code:CFLAGS="$CFLAGS -fPIC -lstdc++" CXXFLAGS="$CXXFLAGS -fPIC"
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)
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
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).
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].
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.
__________________
modRana: a flexible GPS navigation system
Mieru: a flexible manga and comic book reader
Universal Components - a solution for native looking yet component set independent QML appliactions (QtQuick Controls 2 & Silica supported as backends)
modRana: a flexible GPS navigation system
Mieru: a flexible manga and comic book reader
Universal Components - a solution for native looking yet component set independent QML appliactions (QtQuick Controls 2 & Silica supported as backends)
| The Following 6 Users Say Thank You to MartinK For This Useful Post: | ||
|
|
2018-06-03
, 05:27
|
|
Posts: 1,414 |
Thanked: 7,547 times |
Joined on Aug 2016
@ Estonia
|
#490
|
@MartinK, it builds static and shared versions of the library. I would suggest to add
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?
Code:
--disable-static
Does it build on your PC?
| The Following 5 Users Say Thank You to rinigus For This Useful Post: | ||
 |
| Tags |
| geocoder, linux, offline maps, router, sailfish os, tiles |
«
Previous Thread
|
Next Thread
»
|
All times are GMT. The time now is 15:26.
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.