3

Only a minimum amount of work is done at compile time by the linker; it only records what library routines the program needs and the index names or numbers of the routines in the library. (source)

So it means ld.so won't check all libraries in its database,only those recorded by the application programe itself, that is to say, only those specified by gcc -lxxx.

This contradicts with my previous knowledge that ld.so will check all libraries in its database one by one until found.

Which is the exact case?

Je Rog
  • 5,675
  • 8
  • 39
  • 47
  • This question is confusing. What are you expecting ld.so to check its database for? – Omnifarious Jun 11 '11 at 04:00
  • @Omnifarious ,as we know libraries names are embeded into the application binary,my question is: will loader 1. **only** check for libraries matching the names or 2. **all** it can find? – Je Rog Jun 11 '11 at 04:03
  • I figured that's what you were asking. And the answer isn't quite that simple. It only checks for libraries matching the names. But libraries themselves can add new names to that list. Each library and executable contains a list of the library names they depend on. – Omnifarious Jun 11 '11 at 04:10

1 Answers1

4

I will make a stab at answering this question...

At link time the linker (not ld.so) will make sure that all the symbols the .o files that are being linked together are satisfied by the libraries the program is being linked against. If any of those libraries are dynamic libraries, it will also check the libraries they depend on (no need to include them in the -l list) to make sure that all of the symbols in those libraries are satisfied. And it will do this recursively.

Only the libraries the executable directly depends on via supplied -l parameters at link time will be recorded in the executable. If the libraries themselves declared dependencies, those dependencies will not be recorded in the executable unless those libraries were also specified with -l flags at link time.

Linking happens when you run the linker. For gcc, this usually looks something like gcc a.o b.o c.o -lm -o myprogram. This generally happens at the end of the compilation process. Underneath the covers it generally runs a program called ld. But ld is not at all the same thing as ld.so (which is the runtime loader). Even though they are different entities they are named similarly because they do similar jobs, just at different times.

Loading is the step that happens when you run the program. For dynamic libraries, the loader does a lot of jobs that the linker would do if you were using static libraries.

When the program runs, ld.so (the runtime loader) actually hooks the symbols up on the executable to the definitions in the shared library. If that shared library depends on other shared libraries (a fact that's recorded in the library) it will also load those libraries and hook things up to them as well. If, after all this is done, there are still unresolved symbols, the loader will abort the program.

So, the executable says which dynamic libraries it directly depends upon. Each of those libraries say which dynamic libraries they directly depend upon, and so forth. The loader (ld.so) uses that to decide which libraries to look in for symbols. It will not go searching through random other libraries in a 'database' to find the appropriate symbols. They must be in libraries that are in the dependency chain.

Omnifarious
  • 54,333
  • 19
  • 131
  • 194
  • @Omnifarious,good job,this clarified the run-time doubt but introduced the link-time doubt for me as your remark `At compile/link time the linker (not ld.so) will make sure that all the symbols the .o files that are being linked together are satisfied by the libraries the program is being linked against.` in the 2nd paragraph sounds ambiguous to me .. – Je Rog Jun 11 '11 at 04:18
  • @Je Rog: I tried to clarify. I think you are being confused by the distinction between 'linking' and 'loading'. 'linking' happens at compile time, when you are creating the executable. 'loading' happens every time the program is run. `ld.so` is the loader, not the linker. Dynamic libraries are weird because much of the job a linker would do at compile time the loader ends up doing when the program is run. This makes the distinction between a linker and a loader somewhat obscure. – Omnifarious Jun 11 '11 at 04:26
  • @Omnifarious,I doubt the correctness of this remark: `If any of those libraries are dynamic libraries, it will not check to make sure that all of the symbols in those libraries are satisfied.` – Je Rog Jun 11 '11 at 04:55
  • @Je Rog: I'll test, but I'm pretty sure that's correct. I don't think that check happens at link time, just at load time. – Omnifarious Jun 11 '11 at 04:59
  • @Omnifarious ,I just made an experiment to prove it's wrong.The link will fail if a symbol is not satisfied in the dynamic libraries. And the procedure is simple,just add a new function `int ha();` in the header file of the `.so`,and call it in the `.c` file that uses this shared library,will get an error :`main.c:(.text+0x33): undefined reference to 'ha' collect2: ld returned 1 exit status` – Je Rog Jun 11 '11 at 05:00
  • @Je Rog: You are correct. This step is done at both link and load time. And your test is too simple. The library has to require a non-existent symbol for your test to be valid. In your test, only the .o files that make up the eventual executable have a dependency on the symbol. But I ran the more complex test by creating some very simple and tiny shared libraries of my own. And you are correct. – Omnifarious Jun 11 '11 at 05:14