• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 53 subscribers
  • Views 337 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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-02.00.00.00

Mark Doyle
Intellectual 295 points

Tool/software: TI C/C++ Compiler

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

$ LD_DEBUG=libs ./ld-2.19-2014.08-1-git.so ./SG5BoardTest ram
371: find library=librt.so.1 [0]; searching

371: search cache=/etc/ld.so.cache
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/ld.so.cache 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?

Thanks

  • 0
    TI__Guru*** 125136 points

    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?

  • 0 in reply to Bin Liu
    Intellectual 295 points

    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 ./ld-2.28.so ./SG5BoardTest6 ram
    1218: find library=librt.so.1 [0]; searching
    1218: search cache=/etc/ld.so.cache
    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.

  • 0 in reply to Mark Doyle
    TI__Guru*** 125136 points

    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.

  • 0 in reply to Mark Doyle
    Intellectual 295 points

    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.

  • 0 in reply to Mark Doyle
    Intellectual 295 points

    I think the answer is all linkers use that build in path. See lists.linaro.org/.../005364.html

    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.
  • 0 in reply to Mark Doyle
    TI__Guru*** 125136 points

    Thanks for the update. It is helpful.