Linker (ld) can't find any external libraries

We are using boost and I have managed to build it with the correct compiler for Toradex. However, I can’t seem to get it to link to the libraries. This is a c++ program using a Makefile using VSC and ApolloX torizon extension. All has been going well, until I tried to link with the boost libraries. I used the customary -Lpathtomylibs in LDFLAGS, but it says it can’t find the library:

/usr/lib/gcc-cross/aarch64-linux-gnu/12/…/…/…/…/aarch64-linux-gnu/bin/ld: cannot find -lboost_log.a:

I don’t have any issues with the compiler, just the linker. If I run the help, it accepts the -LDIRECTORY, but it still says it can’t find the file. Using --help with the ld command says it will work with the -L command and add the directory. I could see if it decided it was the wrong format or something, but it is very stubborn and says it can’t find it.
Any ideas with be helpful.

How are you installing the boost-log lib? Ideally, you can just add the package ( to your Dockerfile with apt install and specify -lboost_log (notice the minor case l).

Here’s a minimum working example of using this specific lib (using a running Debian container, modify your project files accordingly instead)

root@a496f83d5e85:/# # apt install libboost-log-dev
root@a496f83d5e85:/# cat 
#include <boost/log/core.hpp>
#include <boost/log/trivial.hpp>
#include <boost/log/expressions.hpp>

int main() {
        boost::log::trivial::severity >= boost::log::trivial::info

    BOOST_LOG_TRIVIAL(info) << "Hello, World!";

    return 0;
root@a496f83d5e85:/# gcc -o hello.out -lpthread -lboost_log -lstdc++
root@a496f83d5e85:/# ./hello.out 
[2024-01-03 10:52:22.769696] [0x0000ffff91267440] [info]    Hello, World!

OK. So after reading a whole bunch of stuff about boost, in order to get it to link statically, you must build boost statically, even though the .a libraries are there that you need. Then I had to remove all my original libs and copy the static libboost*.a libraries to my local project lib folder (pointing to it via the -L option) and now it links like it’s supposed to. Apparently, if you have the .so’s in the directory, it still looks tries to link dynamically, even though the headers get changed to a static link path. Super crazy.

Thanks a lot for publishing your solution :slight_smile:

Out of pure curiosity: is there any reason you prefer having it statically linked?

Yes, dynamically linking can actually cause multiple instances to be used at the same time, and can use up more memory. Additionally, static linking only uses the actual code it needs out of the library, you don’t carry the entire load, so it can use less space ultimately, unless of course, you need the entire thing. :slight_smile:


1 Like