Issue with socktap's gpsd dependency on ARM 32bit architecture
Closed this issue · 8 comments
Hello,
I tried to compile socktap for a ARM 32bit architecture. Therefore I cross compiled Boost, Crypto++, GeographicLib and gpsd (libgps.a is placed under /home/user/vanetza-deps/lib and gps.h under /home/user/vanetza-deps/include).
The compilation of socktap fails, see attached log.
socktap_build.txt
First of all, I would check if libgps.a is actually linked into the executable. I suggest to call make VERBOSE=1 to see the linker call including all arguments. If you have confirmed that libgps.a is considered by the linker then I suspect that something went wrong when compiling libgps.
@riebl: Thanks for your fast answer. I executed your suggestion, but unfortunately I'm not sure how to interpret
socktap_build_verbose.txt
the outcome.
The interesting part is at the end of your log file:
[ 99%] Linking CXX executable ../../bin/socktap-hello
cd /home/user/vanetza/vanetza-build/tools/socktap && /usr/bin/cmake -E cmake_link_script CMakeFiles/socktap-hello.dir/link.txt --verbose=1
/home/user/toolchain/gcc-linaro-7.3.1-2018.05-x86_64_arm-linux-gnueabihf/bin/arm-linux-gnueabihf-g++ -rdynamic CMakeFiles/socktap-hello.dir/hello_application.cpp.o CMakeFiles/socktap-hello.dir/main_hello.cpp.o -o ../../bin/socktap-hello -Wl,-rpath,/home/user/vanetza-deps/lib: ../../lib/static/libsocktap-common.a /home/user/vanetza-deps/lib/libboost_system.so.1.71.0 /home/user/vanetza-deps/lib/libboost_program_options.so.1.71.0 /home/user/vanetza-deps/lib/libgps.a ../../lib/static/libvanetza_asn1_security.a ../../lib/static/libvanetza_asn1_pki.a ../../lib/static/libvanetza_btp.a ../../lib/static/libvanetza_facilities.a ../../lib/static/libvanetza_asn1.a ../../lib/static/libvanetza_asn1_its.a ../../lib/static/libvanetza_asn1_support.a ../../lib/static/libvanetza_geonet.a ../../lib/static/libvanetza_dcc.a ../../lib/static/libvanetza_access.a ../../lib/static/libvanetza_gnss.a ../../lib/static/libvanetza_security.a ../../lib/static/libvanetza_net.a ../../lib/static/libvanetza_common.a -pthread /home/user/vanetza-deps/lib/libboost_date_time.so.1.71.0 /home/user/vanetza-deps/lib/libGeographic.so.19.0.0 /home/user/vanetza-deps/lib/libcryptopp.so
The good thing is that it contains /home/user/vanetza-deps/lib/libgps.a, i.e. the build process itself looks fine as it tries to link the libgps.a static library into the executable socktap-hello.
The bad thing is that you still get undefined reference errors. The missing symbols gps_open etc. all belong to libgps.
Please check if your /home/user/vanetza-deps/lib/libgps.a library contains the missing symbols at all. You can use the nm tool for that, however, you need to use the one from your ARM toolchain.
Thanks for your support. You're right, libgps.a doesn't contain the symbols. I switched to a precompiled library. The compilation of socktap fails because of 'undefined references', although the required dependencies/libs are already added.
/home/user/vanetza-deps/lib/libdbus-1.so.3: undefined reference to fcntl64@GLIBC_2.28'
/home/user/vanetza-deps/lib/libgps.so.25: undefined reference to fcntl@GLIBC_2.28' /home/user/vanetza-deps/lib/libgps.so.25: undefined reference to pow@GLIBC_2.29'
`
It seems that above undefined references are well known issues in general. I adjust the cmake file with corresponding changes, but there is still no effort. So it requires further investigation. I think it must be checked first if there is maybe a 'cross dependency' with other dependencies of vanetza.?
Toolchaiin.cmake.txt
socktap_build_libgps25.txt
dependencies.txt
If your target system is not a Fedora 31 ARM Linux system then I highly discourage you to "drag & drop" its libgps. In good cases, you will just see error messages as you have, in bad cases things may silently go wrong.
Do you need GPS for socktap on your target system? If not, I may refactor socktap so that the gpsd dependency becomes optional.
@riebl: No, I dont need the GPS. A socktap variant without gpsd dependency would be great!
Thanks a lot!