Re: obsoleting shlibs - what's the plan

[Joerg Sonnenberger <joerg%britannica.bec.de@localhost>]

On Mon, Apr 14, 2008 at 03:52:02AM +0000, David Holland wrote:
> On Sat, Mar 29, 2008 at 12:36:14PM +0900, Joerg Sonnenberger wrote:
>  > > It's also not clear that loading two instances of the "same" library
>  > > is necessary wrong in all cases. For example, a library that provided
>  > > the functions in <string.h> could be cloned fairly safely, whereas two
>  > > different mallocs is clearly a losing proposition no matter what you
>  > > do.
>  > 
>  > A different malloc is actually safe as well as long as you implement the
>  > whole family.
> 
> Not really. If a pointer returned by one malloc's malloc makes its way
> to the other malloc's free, nothing good can possibly happen.

I am not talking about mixing mallocs. I am talking about *replacing*
one completely. Given that it is not supposed to have a hidden
interface, it has to work. The list of symbols to override has recently
changed though as some people assumed posix_memalign is a bright idea.

> Also, with many malloc implementations they'll fight over the process
> break and get seriously confused.

I would expect a modern malloc implement to not use anachronistic
interfaces. mmap is almost always superior to break.

> 
>  > At least libpthread and libc should check explicitly that
>  > they are loaded only once. In the caes of libpthread, it should also
>  > check and fail miserable when it is loaded via dlopen.
> 
> It's not clear that this can be done without help from the dynamic
> linker.

Constructor is enough for libc and libpthread has an explicit init call
already. It just has to also implement a counter shared by the
instances.

Joerg