This is the mail archive of the
mailing list for the glibc project.
Re: Prelinking of shared libraries
On Sat, May 05, 2001 at 10:47:14AM +0200, Andreas Jaeger wrote:
> Why has the configuration program to work on system binaries?
a) you want to prelink the binaries as well now that you know where exactly
will the libraries (if everything goes right) be
b) for conflicts - although you can compute partial conflicts for each
library, you have to compute conflicts for the binary as well (because it
is also the binary which influences link scopes and library load order);
and I think (thought testing would tell more) that it is better to have
conflicts in binaries only.
A few examples:
- say libA provides foo symbol, libB DT_NEEDED libA uses it.
So obviously libB's call to foo will be resolved to libA's one.
Now you link binary D DT_NEEDED libC, libB. libC is yet another shared
library, defining foo as well. In this case binary D has to note
conflict that it should undo the prelinked relocation in libB (the
conflict can have various shape, e.g. it can be just "undo" information
and ld.so would have to resolve the relocation at runtime, or
it can be yet another relocation against the same place which will
adjust the conflicting place so that it contains the right value).
- similarly if the main binary exports some symbol, it should have
conflicts if some libraries use it and normally find it elsewhere
- many conflicts will result especially if applications are linked with
-lpthread - in this case it would be worth considering teaching the
configuration program about the most common conflicts in most widely
used libraries (it could be done automatically, during the whole
prelinking process it could gather statistics about which conflicts
are present most, output them at the end into some configuration file
and could use it next time (and as the set of these symbols IMHO does
not change too often, it could be shipped by the distribution makers
and so prelinking would not have to be done twice each time)) - this
would work only for JUMP_SLOT kind of relocations and I don't know
yet what would have to be done during LD_BIND_NOW=1 in this case.
I believe exactly these -lpthread conflicts is what Uli had in mind
when saying about the complications.