2015-12-01 23:26 GMT+08:00 Ryan Arnold ryan.arnold@linaro.org:

On Tue, Dec 1, 2015 at 1:24 AM, Barry Song 21cnbao@gmail.com wrote:

...

hi guys, sorry maybe my question is stupid as i am not a toolchain guy.

i have no idea why ld.so search so many paths. for example, put "-rpath" with /home/cnb1szh/test in a simple test program. then during dynamic linking at runtime, we get the below linking debug information:

30693: find library=libmytest.so [0]; searching

30693: search path=/home/cnb1szh/test/tls/v7l/neon/vfp:/home/cnb1szh/test/tls/v7l/neon:/home/cnb1szh/test/tls/v7l/vfp:/home/cnb1szh/test/tls/v7l:/home/cnb1szh/test/tls/neon/vfp:/home/cnb1szh/test/tls/neon:/home/cnb1szh/test/tls/vfp:/home/cnb1szh/test/tls:/home/cnb1szh/test/v7l/neon/vfp:/home/cnb1szh/test/v7l/neon:/home/cnb1szh/test/v7l/vfp:/home/cnb1szh/test/v7l:/home/cnb1szh/test/neon/vfp:/home/cnb1szh/test/neon:/home/cnb1szh/test/vfp:/home/cnb1szh/test (RPATH from file ./hello)

30693: trying file=/home/cnb1szh/test/tls/v7l/neon/vfp/libmytest.so

30693: trying file=/home/cnb1szh/test/tls/v7l/neon/libmytest.so

30693: trying file=/home/cnb1szh/test/tls/v7l/vfp/libmytest.so

30693: trying file=/home/cnb1szh/test/tls/v7l/libmytest.so

30693: trying file=/home/cnb1szh/test/tls/neon/vfp/libmytest.so

30693: trying file=/home/cnb1szh/test/tls/neon/libmytest.so

30693: trying file=/home/cnb1szh/test/tls/vfp/libmytest.so

30693: trying file=/home/cnb1szh/test/tls/libmytest.so

30693: trying file=/home/cnb1szh/test/v7l/neon/vfp/libmytest.so

30693: trying file=/home/cnb1szh/test/v7l/neon/libmytest.so

30693: trying file=/home/cnb1szh/test/v7l/vfp/libmytest.so

30693: trying file=/home/cnb1szh/test/v7l/libmytest.so

30693: trying file=/home/cnb1szh/test/neon/vfp/libmytest.so

30693: trying file=/home/cnb1szh/test/neon/libmytest.so

30693: trying file=/home/cnb1szh/test/vfp/libmytest.so

30693: trying file=/home/cnb1szh/test/libmytest.so

but we don't have /home/cnb1szh/test/tls/, /home/cnb1szh/test/v7l/, /home/cnb1szh/test/vfp/, /home/cnb1szh/test/neon/, why does the ld.so search so many paths?

-barry _______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain

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.

This is not a bug.

What this does is allows the Linux distribution to provide optimized versions of the libraries in each of those directories. The optimized versions of the library have the most efficient code-gen for the capability present. For instance, in your own library, if you wanted to have a neon optimized version and a non-neon optimized version you'd put the neon one in test/neon/ and the non-optimized version in test/ directly.

Hi Ryan, thanks a lot! i am wondering whether ld.so will check the capbility of ARM to decide which version should be used. for example, suppose we have a platform like this:

1. there is no neon in ARM chips, 2. in the filesystem, there is a lib using neon and the other lib without neon

will ld.so use the 2nd lib automatically and ignore the 1st search path with neon?

if there is no this capbility, it seems the feature is not making so many senses?

-- Ryan S. Arnold Linaro Toolchain Working Group - Engineering Manager www.linaro.org

-barry