Re: PATCH: Handle DF_1_INTERPOSE

["H. J. Lu" <hjl at lucon dot org>]

On Fri, May 30, 2003 at 10:53:56PM -0700, Ulrich Drepper wrote:
> > Like any shared libraries,
> > things can go wrong if it is not used appropriately.
> 
> And no, it's not some problem you can brush over with a comment like
> this.  It has only any effect until everybody uses it since the next DSO
> maintainer thinks her/his DSO has equal rights to be added to the front.
> 
> This is a ill-designed extension.  It is impossible to figure out what
> the behavior of the application will be since it is not visible what the
> final order in the search scope will be.  The standard ELF lookup format
> works well because it is absolutely clear what the order is, it's
> standardized.
> 

I don't think DF_1_INTERPOSE introduces more complications than
DT_NEEDED. You just move the one marked with DF_1_INTERPOSE in the old
search order to the front until you reach the end of the list.

> 
> > We find a need to interpose some functions in libc.so automatically
> > independent of the link order without using LD_PRELOAD. "-z interpose"
> > does what we need.
> 
> Still no reason.
> 
> I see no reason to add this until I see real evidence for the usefulness.
> 

We have a DSO. When it is linked in, libc.so has to be thread safe. But
libpthead can't be linked in. That DSO overrides some functions in
libc.so to make it thread safe. It works in glibc 2.2 since those libc
functions are weak and global ones can override them. But it is no
longer true for glibc 2.3. What is the best way to make libc.so thread
safe reliably without using libpthread? BTW, the same DSO should work
with both glibc 2.2 and 2.3.



H.J.