Date: Sat, 07 Feb 2004 01:00:01 -0700 From: Scott Long <scottl@freebsd.org> To: David Schultz <das@FreeBSD.org> Cc: current@FreeBSD.org Subject: Re: HEADS UP: libkse -> libpthread switch Message-ID: <40249B01.7000102@freebsd.org> In-Reply-To: <20040207072710.GA1369@VARK.homeunix.com> References: <20040205072422.GB11291@VARK.homeunix.com> <4023C100.2090305@freebsd.org> <20040207005520.GA7132@VARK.homeunix.com> <20040207.000718.29363133.imp@bsdimp.com> <20040207072710.GA1369@VARK.homeunix.com>
next in thread | previous in thread | raw e-mail | index | archive | help
David Schultz wrote: > On Sat, Feb 07, 2004, M. Warner Losh wrote: > >>In message: <20040207005520.GA7132@VARK.homeunix.com> >> David Schultz <das@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?40249B01.7000102>