I have been writing a dependency checker for slackware binaries.
It works, but is generating false detects because ldd is falsely outputting "not found".

The libraries that are not found all are shipped with the binary in their own lib directory. When one of the libraries in the dedicated lib directory references another in that same directory, ldd does not detect it.

It seems that ldd only find libraries that are in one of the common library directories.

Question: It has been said that shipping your binary with needed libraries in the same directory with the executable is supposed to work. Those libraries are supposed to be found first.

All my reading of dynamic linking order and reading ld man page cannot prove that.

I have packages that are seem to be doing exactly that, and they work.
They are the ones that ldd is falsely, not found.

I have checked by running the program and using lsof and fuser to see that the libraries that supposedly were "not found" were actually opened and were in use.

I am curious if others could report of the same behavior of ldd on their systems.
Is this systematic of ldd, or do I have some bad setup.
Please give evidence of your testing, not wild guessing.


Firefox
/usr/lib/firefox/libmozavcodec.so
- libmozavutil.so not found
(it is actually right there in the same directory)

seamonky
/usr/lib/seamonkey/libmozavcode.so
- libmozavutil.so not found
/usr/lib/seamonkey/libxul.so
- libldap60.so not found
- libprldap60.so not found
- libmozgtk.so not found
- liblgpllibs.so not found
- libmozsandbox.so not found
- libmozsqlite.so not found

wine
/usr/lib/wine/i386-unix/libxul.so
(same missing as in seamonkey)
/usr/lib/wine/i386-unix/bcrypt.so (and many others)
ntdll.so not found



quicktime
/usr/lib/libquicktime/lqt_x264.so
libx264.so.148 not found
(This one may be real, as I have /usr/lib/libx264.163)

ldd uses the current environment to find libraries. check man ld.so to see how does it look for libraries and what environment variables are used.

I thought I would try on my system and you're right I did get not found for firefox and seamonkey although mine are in lib64. I checked using ldconfig.
This did not find them. So I added to my /etc/ld.so.conf file. I checked ldconfig and ldd again and it resolved the issue. Now I feel that if I am going to put exceptions into ld.so.conf it should be in the directory /etc/ld.so.conf.d/ with files names firefox.conf and seamonkey.conf.
Since I did not notice any failures of firefox or seamonkey is this fixing a non fault. The software probably link the libraries at runtime so the output of ldd is not meaningful in that case. Keep looking because I don't know the answers to this.

Kind regards

Dunc.

Mine is attached. Patrick Volkerding has also posted one he uses in LQ but I do not have a link at hand for his message.

Attached Files

deps_not_found.sh.txt (609 Bytes, 51 views)

2 members found this post helpful.

ldd, like the dynamic linker searches, like others have said, in directories specified by /etc/ld.so.conf. It can also search in directories specified by the LD_LIBRARY_PATH environment variable.

Example:

Yes, by default in only searches in "common" library directories, but the dynamic linker can be made to search in more directories.

This might be true, but it depends upon how the binary was linked when built. If linked with no special flags only "common" directories will be searched for dynamic libraries by the dynamic linker. However, if linked with the flag:

the binary will search for dynamic libraries in the same directory as the binary lives in.

regards Henrik

2 members found this post helpful.

FYI, you may get inspired by revdep and finddeps, found in CRUX, part of their prt-utils:

https://crux.nu/files/tools/prt-utils/

I had look at these tools and their man page and do not think that they can answer OP's question as they assume the existence of a ports or packages database that does not exist in Slackware in the same form.

PS As it happens I just installed CruxVoid in a VM today as they claim that the live ISO is now accessible with Braille and speech

firefox etc set LD_LIBRARY_PATH. For example, if firefox is running, this command shows the values of the environment variables of all the children processes of the parent firefox:

The environment variables seem to be in alphabetical order, so it's not so difficult to find LD_LIBRARY_PATH. But if you can't find it, this will find it for you:
I'm not sure this is a good idea. The libraries in /usr/lib64/firefox are meant to be private to firefox. Package mozilla-nss exposes many libraries publicly (to other programs) in /usr/lib64 with same names (libfreeblpriv3.so libnspr4.so libnss3.so libnssckbi.so libnssutil3.so libplc4.so libplds4.so libsmime3.so libsoftokn3.so libssl3.so) as can also be found in /usr/lib64/firefox. If you have /usr/lib64 before /usr/lib64/firefox in ld.so.conf, I guess the correct one in /usr/lib64 is used, though.

3 members found this post helpful.

ok.

Just so you know,
I read that man page for ld.so and the man page for ld, ldconfig, etc., over and over again. They are not clear on anything except that they search some libraries specified by some environment variables,
and then the standard libraries.

I can find no sign of those environment variables, and they do not explain how what I described in the question would work.
LD_LIBRARY_PATH, saw that could not find where it was defined.
It is mentioned that the running program has this set.
But I have to find it without running the program.


I cannot go patching up ld cache for this. Also may cause problems (see Petri Kaukasoina post)
The programs work, it is only ldd that is not reporting correctly.

This still shows that ldd is weak and does NOT do all that is described.
It would need a switch that enabled it to look into the binary and extract that LD_LIBRARY_PATH, and check there too.

If this is only working because the program sets LD_LIBRARY_PATH using some system function, and then is using
dlopen to access the libraries, then I do not know what to do at this point.

I did a grep of the Firefox binary and did not find it.
Did a grep of the .mozilla directory, and it showed up in some saved restore point.
If it is in a different place for every program that might use it, a script has no reliable way to determine what they used.
I think it would be down to just assuming that any lib directory of that program is a probable target of LD_LIBRARY_PATH.
This is not correct, but might detect, or at least prevent false "not found" detections.

With look at that deps_not_found, as it sounds close to what I was writing.
Thank you.

actually I don't know how does firefox work, but usually they rely on the actual environment, especially on LD_LIBRARY_PATH and /etc/ld.so.conf. It was explained already on those man pages.
Additionally any app can load any .so file on the fly, based on its own implementation (see the man page of dlopen).

removed

I think the mozilla apps use rpath so that includes the current directory, as Henrik already noted.

for more info on rpath you can have a look, for example, at the wikipedia page.

The man page for ldconfig mentions the trusted directories: /lib, /usr/lib, /lib64 and /usr/lib64

The tools might not be looking in other directories without encouragement for security reasons.

By default, that environment variable is not defined at all. However, if any user chooses to set the LD_LIBRARY_PATH environment variable the dynamic linker will use the given paths to search for dynamic libraries.

Examples of where to set the LD_LIBRARY_PATH environment variable:

• In some file below /etc/profile.d
• In some login file in your home directory called by your shell. Depending upon your shell this might be .login, .profile, .cshrc or .bashrc.
• In some script used to call a binary executable which needs some environment variables set before it is run.
• Manually in the shell
  Code:

  export LD_LIBRARY_PATH=/my/special/dir:/some/more/stuff

regards Henrik