This is quite long, and not what I expected. You might not want to go down that rabbit hole unless you are fixing bugs related to this. TLDR: Linking and searching seems to be doing as expected, but printing of default search paths via ld
looks like it has a bug (a “normally” cosmetic only issue).
A short answer is that ldconfig
creates “/etc/ld.so.cache
” after consulting search paths such as that from “/etc/ld.so.conf.d/nvidia-tegra.conf
”. This cache file is what the linker actually uses to find content. The cache file is generated correctly, but the option to print the linker’s path (as found in ld.so.cache
) appears to have a bug and simply does not print the path.
I think the linker is important enough that it might be worth NVIDIA’s time to find out why it uses “/usr/lib/aarch64-linux-gnu/tegra/*
”, but fails print that this path is actively searched (other software could use this as a search method and end up with bugs; since other paths are not effected, it might be that the bug is only important to people who put something in a path the linker does not print…implying NVIDIA might find it useful to understand the lack of printing of their tegra/
in the path, although since the path is searched, it might not be a high priority).
Now on to the long tale of printing the missing linker path.
The ld
search path from nvidia-tegra.conf
would only append. This might be wrong, but I see in the search path does include the base:
/usr/lib/aarch64-linux-gnu
Since you’ve looked at “/etc/ld.so.conf.d/nvidia-tegra.conf
” and found “/usr/lib/aarch64-linux-gnu/tegra
” I too would expect to see this in the search path. However, take a look at some of the library .so
files in “/usr/lib/aarch64-linux-gnu/tegra
”. I looked at this on an Xavier NX, found the default search path lacking just as you did, verified this is listed in the nvidia-tegra.conf
for ld
, and then listed all libraries found via “ldconfig -p
” (and grep’d for that library; my example was “libnvidia-glcore
”; I did not check all libraries there are found, but a sample found all that I looked for). Oddly, I found the libraries of that directory are still found by ldconfig -p
. So there are two places left which I know of to check.
One is that ld
will consult libnamespec.so
, followed by libnamespec.a
, but these don’t exist on most systems (including Jetsons). On the other hand, there is one last place this can be found: In the environment variable “LD_LIBRARY_PATH
”, or otherwise passed in the environment. I also don’t see this. I have no idea how “ldconfig -p
” is listing these libraries from “/usr/lib/aarch64-linux-gnu/tegra
”. Odd.
So I followed all of the symbolic links of ld
until I found the actual hard link (on an NX with an R32.x L4T):
/usr/bin/aarch64-linux-gnu-ld.bfd
The above is provided by Ubuntu and is not from NVIDIA. I had wondered if perhaps this was from NVIDIA and modified for the tegra/
search location, but it is not. Confusing mystery.
I did find that the actual location which causes ld
to search there is from “/etc/ld.so.cache
”. This in turn is generated when “ldconfig
” is run (which runs at boot or after a package installs a library). I ran strace
(which monitors system calls to the kernel) and found that indeed ldconfig
does consult “/etc/ld.so.conf.d/nvidia-tegra.conf
”:
openat(AT_FDCWD, "/etc/ld.so.conf.d/nvidia-tegra.conf", O_RDONLY) = 4
This lead to finding “/usr/lib/aarch64-linux-gnu/tegra
”:
newfstatat(AT_FDCWD, "/usr/lib/aarch64-linux-gnu/tegra", {st_mode=S_IFDIR|0755, st_size=12288, ...}, 0) = 0
At this point it is obvious that ld
is in fact doing what it should because ld.so.cache
is correct, and the cache is correct because ldconfig
created it after reading “/etc/ld.so.conf.d/*
”.
I ran strace
on “ld --verbose
”, and indeed it reads from ld.so.cache
. The tegra/
location never shows up in the trace file. Since the cache has that information it seems to be a bug of ld
, at least a bug of the --verbose
option. The tegra/
directory is indeed being found and cached and linked to, but the print of search locations fails to see this, while the printing and actual linking of default libraries found succeeds (the search path listing fails, individual contents do print).