HEADS UP: libkse -> libpthread switch

[Scott Long]

David Schultz wrote:
> On Sat, Feb 07, 2004, M. Warner Losh wrote:
> 
>>In message: <20040207005520.GA7132 at VARK.homeunix.com>
>>            David Schultz <das at freebsd.org> writes:
>>: Maybe I don't understand dynamic linking in FreeBSD well enough,
>>: but an application that is both statically and dynamically linked
>>: against the same library seems bizarre and unusual to me.
>>: Wouldn't the two halves reference different copies of the library,
>>: breaking things like malloc() and gethostbyname() (in the
>>: hypothetical case of libc)?  I don't see how such a thing could
>>: possibly work in the first place.
>>
>>Such a thing is possible if at the time you built library X, it
>>required library Y shared.  You then build program A that requires
>>library X and Y, but link Y static.  Bad things happen after that.
>>Esp if Y is libc or libc_r.
> 
> 
> Yeah, I understand how it can happen, and I've even seen it on a
> Solaris box.[1]  But Scott's message seems to imply that partially
> statically linked binaries work right now, and that we need to
> keep it that way moving into the next release, even at the expense
> of potentially breaking fully dynamic binaries.  Perhaps he meant
> something else.
> 

No, not at all.  My point was that people are going to run into these
hideous edge cases (netscape/mozilla plugins come to mind here), and
our official stance should be to recompile the app.  The important thing
with going into 5.3 is that these kinds of problems need to be very easy
to diagnose by the user, and relatively easy to fix.  I don't want
something that will obfuscate the problem or create a false sense of
security.  The last thing we need is for the mailing lists to get
flooded with people complaining that 5.3 isn't stable merely because
of mis-behaving libraries.

Scott