This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Compiler: Linker Library System Search Path ti-processor-sdk-linux-am437x-evm-

Tool/software: TI C/C++ Compiler

I'm working on an older product that was created with the  ti-processor-sdk-linux-am437x-evm- In debugging, I ran the linker with LD_DEBUG=libs on a program called SG5BoardTest and found:

$ LD_DEBUG=libs ./ ./SG5BoardTest ram
371: find [0]; searching

371: search cache=/etc/
371: search path=/usr/lib/tls/v7l/neon/vfp:/usr/lib/tls/v7l/neon:/usr/lib/tls/v7l/vfp:/usr/lib/tls/v7l:/usr/lib/tls/neon/vfp:/usr/lib/tls/neon:/usr/lib/tls/vfp:/usr/lib/tls:/usr/lib/v7l/neon/vfp:/usr/lib/v7l/neon:/usr/lib/v7l/vfp:/usr/lib/v7l:/usr/lib/neon/vfp:/usr/lib/neon:/usr/lib/vfp:/usr/lib (system search path)

These directories do not exist on the host or target, and don't seem to be in /etc/ or the elf file I'm executing.

The program SG5BoardTest was built with

arm-linux-gnueabihf-gcc -I${USER_COMMON_DIR} SG5BoardTest.c ${USER_COMMON_DIR}/ioutilities.c ${USER_COMMON_DIR}/CellModem.c -lrt -o SG5BoardTest

My question is, how did these /usr/lib/tls directories get into my search path and how do I control the linker system search path?


  • Hi Mark,

    The Processor SDK Linux v2.0 was released many years ago and no longer supported on this forum. Can you please try with the latest SDK release to see if the behavior is still the same?

  • Hi Bin,

    Thanks for the quick response. I build the same program with the latest download SDK 06.03.00 and tried it on the target with the loader from the SDK 06.03.00 and got similar results:

    $ LD_DEBUG=libs ./ ./SG5BoardTest6 ram
    1218: find [0]; searching
    1218: search cache=/etc/
    1218: search path=/lib/tls/v7l/neon/vfp:/lib/tls/v7l/neon:/lib/tls/v7l/vfp:/lib/tls/v7l:/lib/tls/neon/vfp:/lib/tls/neon:/lib/tls/vfp:/lib/tls:/lib/v7l/neon/vfp:/lib/v7l/neon:/lib/v7l/vfp:/lib/v7l:/lib/neon/vfp:/lib/neon:/lib/vfp:/lib:/usr/lib/tls/v7l/neon/vfp:/usr/lib/tls/v7l/neon:/usr/lib/tls/v7l/vfp:/usr/lib/tls/v7l:/usr/lib/tls/neon/vfp:/usr/lib/tls/neon:/usr/lib/tls/vfp:/usr/lib/tls:/usr/lib/v7l/neon/vfp:/usr/lib/v7l/neon:/usr/lib/v7l/vfp:/usr/lib/v7l:/usr/lib/neon/vfp:/usr/lib/neon:/usr/lib/vfp:/usr/lib (system search path)

    This isn't a big deal; I was setting up a new root file system and making sure the libraries were in the right place when I noticed this odd search path. I was just curious.

  • Hi Mark,

    I don't have an exact answer (as I am a kernel guy, barely do user space programming...), but what I think is that this search path is for the program runtime linking libs, so all the paths start with '/lib/' or '/usr/lib/', which should be the directory layout on the target filesystem, instead of '<cross-toolchain>/{,usr}/lib/' on the host. Hopefully this makes sense.

  • Thanks again. As I said, this isn't a big issue. If there is no way to control the library search path, I can always make a link from the first directory in the path to my actual library directory.

  • I think the answer is all linkers use that build in path. See

    The relevant part is:

    Hi Barry, this is a known, intentional behavior of the dynamic-linker.
    > It defaults to searching for libraries in a tls directory (the glibc
    > developers intend to remove this since linux-threads are now gone and nptl
    > is the standard but no-one has stepped forward to do so), then directories
    > based on the cpu, then directories that are based on the hardware
    > capabilities for the platform (AT_HWCAP for 'arm') in various combinations.
    > This is why you see it searching the different variations of directories.
  • Thanks for the update. It is helpful.