Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cross compiler can't find usr/lib/arm-linux-gnueabihf #5

Open
buelowp opened this issue Apr 19, 2020 · 3 comments
Open

Cross compiler can't find usr/lib/arm-linux-gnueabihf #5

buelowp opened this issue Apr 19, 2020 · 3 comments

Comments

@buelowp
Copy link

buelowp commented Apr 19, 2020

I'm using cmake, but that shouldn't matter. I am able to build binaries, but when it needs to search the rootfs to link against usr/lib/arm-linux-gnueabihf, it can't find that path. I've been experimenting with some options, but it would be nice if the toolchain could find that path too if possible. Thank you.

@Pro
Copy link
Owner

Pro commented Apr 19, 2020

Are you using the Toolchain file here? That one should work:
https://github.com/Pro/raspi-toolchain/blob/master/Toolchain-rpi.cmake

Also make sure that the rootfs path for the cmake path is correct.
Use cmake and make debugging flags to print out search paths and so on. This should help identifying the problem

@buelowp
Copy link
Author

buelowp commented Apr 19, 2020

I was not, but using one I built. I switched to yours, but still have some issues. I think your toolchain cmake assumes the cross compiler is in the path, correct? I don't generally put my cross compilers in my path, I create the path in my toolchain files. Should work both ways, but asking anyway.

Also, I need to add the following as this toolchain cmake doesn't find the system include path correctly.

ADD_DEFINITIONS ("-isystem /opt/rpi-rootfs/usr/include")

I think this is just something I'm missing with cmake, but I've seen it used in other cross environments, and it works for me for a few of my own. I tend to fall back on it as it works, but if you have some insight into how to get the cmake SYSROOT master find things correctly, I would love to know what that is.

Finally, my libraries link just fine with the correct cross libs paths, but not my final executable. I build a lot of static libs and then link it all at the end. Note, the add_executable() and target_link_libraries() don't seem to behave correctly where the other add_library with target_link_library does work. Any thoughts on why this doesn't work like I would expect?

cd /work/Projects/github/aquarium/build/mcp3008 && /opt/cross-pi-gcc/bin/arm-linux-gnueabihf-g++ --sysroot=/opt/rpi-rootfs   -I/work/Projects/github/aquarium/build/mcp3008 -I/work/Projects/github/aquarium/mcp3008 -I/work/Projects/github/aquarium/timer -I/work/Projects/github/aquarium/atlas -I/work/Projects/github/aquarium/app  -mcpu=arm1176jzf-s -mfpu=vfp -mfloat-abi=hard -I/opt/rpi-rootfs/usr/include  -L/opt/cross-pi-gcc/arm-linux-gnueabihf/lib -Wl,-rpath-link,/opt/cross-pi-gcc/arm-linux-gnueabihf/lib -L/opt/cross-pi-gcc/lib -Wl,-rpath-link,/opt/cross-pi-gcc/lib -L/opt/rpi-rootfs/opt/vc/lib -Wl,-rpath-link,/opt/rpi-rootfs/opt/vc/lib -L/opt/rpi-rootfs/lib/arm-linux-gnueabihf -Wl,-rpath-link,/opt/rpi-rootfs/lib/arm-linux-gnueabihf -L/opt/rpi-rootfs/usr/local/lib -Wl,-rpath-link,/opt/rpi-rootfs/usr/local/lib -L/opt/rpi-rootfs/usr/lib/arm-linux-gnueabihf -Wl,-rpath-link,/opt/rpi-rootfs/usr/lib/arm-linux-gnueabihf -L/opt/rpi-rootfs/usr/lib -Wl,-rpath-link,/opt/rpi-rootfs/usr/lib -L/opt/rpi-rootfs/usr/lib/arm-linux-gnueabihf/blas -Wl,-rpath-link,/opt/rpi-rootfs/usr/lib/arm-linux-gnueabihf/blas -L/opt/rpi-rootfs/usr/lib/arm-linux-gnueabihf/lapack -Wl,-rpath-link,/opt/rpi-rootfs/usr/lib/arm-linux-gnueabihf/lapack   -isystem /opt/rpi-rootfs/usr/include -isystem /opt/rpi-rootfs/usr/include -std=gnu++17 -o CMakeFiles/mcp3008.dir/mcp3008.cpp.o -c /work/Projects/github/aquarium/mcp3008/mcp3008.cpp
[ 76%] Linking CXX static library libmcp3008.a

[ 84%] Linking CXX executable aquarium
cd /work/Projects/github/aquarium/build/app && /usr/bin/cmake -E cmake_link_script CMakeFiles/aquarium.dir/link.txt --verbose=1
/opt/cross-pi-gcc/bin/arm-linux-gnueabihf-g++ --sysroot=/opt/rpi-rootfs  -fcompare-debug-second  -rdynamic CMakeFiles/aquarium.dir/main.cpp.o  -o aquarium -lwiringPi ../atlas/libatlas.a ../timer/libtimer.a ../mcp3008/libmcp3008.a ../temperature/libds18b20.a ../errors/liberrors.a ../mqtt/libmqtt.a ../configuration/libconfiguration.a -lconfig++ -lpaho-mqttpp3 -lpaho-mqtt3as -lssl -pthread 
/opt/cross-pi-gcc/lib/gcc/arm-linux-gnueabihf/8.3.0/../../../../arm-linux-gnueabihf/bin/ld: cannot find -lconfig++
/opt/cross-pi-gcc/lib/gcc/arm-linux-gnueabihf/8.3.0/../../../../arm-linux-gnueabihf/bin/ld: cannot find -lssl

*** Edit***
Adding my add_executable if you care

add_executable (${PROJECT_NAME} ${SOURCES})

target_link_libraries (${PROJECT_NAME} Threads::Threads -lwiringPi
                    ${CMAKE_BINARY_DIR}/atlas/libatlas.a
                    ${CMAKE_BINARY_DIR}/timer/libtimer.a
                    ${CMAKE_BINARY_DIR}/mcp3008/libmcp3008.a
                    ${CMAKE_BINARY_DIR}/temperature/libds18b20.a
                    ${CMAKE_BINARY_DIR}/errors/liberrors.a
                    ${CMAKE_BINARY_DIR}/mqtt/libmqtt.a
                    ${CMAKE_BINARY_DIR}/configuration/libconfiguration.a
                    ${LIBCONFIG_LIBRARIES} -lpaho-mqttpp3 -lpaho-mqtt3as ${OPENSSL_LIBRARIES})

@ali1234
Copy link

ali1234 commented Aug 4, 2021

"/usr/lib/arm-linux-gnueabihf missing from the search path" - That happens when your toolchain doesn't have this debian-specific patch: https://github.com/ali1234/rpi-toolchain/blob/buster/patches/binutils/2.31.1/129_multiarch_libpath.patch

"my libraries link just fine with the correct cross libs paths, but not my final executable. I build a lot of static libs and then link it all at the end" This one usually happens because of a debian specific patch in libtool. The workaround is to make sure your libtool does not have the debian-specific patch, because it totally breaks cross compiling. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=297726

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants