View Single Post
Posts: 1,548 | Thanked: 7,510 times | Joined on Apr 2010 @ Czech Republic
#489
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.
__________________
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: