This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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.

	Jakub


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]