From owner-freebsd-current@FreeBSD.ORG Sat Feb 7 00:02:31 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1501616A503 for ; Sat, 7 Feb 2004 00:02:31 -0800 (PST) Received: from smtp.mho.com (smtp.mho.net [64.58.4.5]) by mx1.FreeBSD.org (Postfix) with SMTP id E78BD43D39 for ; Sat, 7 Feb 2004 00:02:30 -0800 (PST) (envelope-from scottl@freebsd.org) Received: (qmail 82134 invoked by uid 1002); 7 Feb 2004 08:02:28 -0000 Received: from unknown (HELO freebsd.org) (64.58.1.252) by smtp.mho.net with SMTP; 7 Feb 2004 08:02:28 -0000 Message-ID: <40249B01.7000102@freebsd.org> Date: Sat, 07 Feb 2004 01:00:01 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5) Gecko/20031103 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Schultz 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> In-Reply-To: <20040207072710.GA1369@VARK.homeunix.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: nectar@FreeBSD.org cc: deischen@FreeBSD.org cc: ports@FreeBSD.org cc: current@FreeBSD.org Subject: Re: HEADS UP: libkse -> libpthread switch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Feb 2004 08:02:31 -0000 David Schultz wrote: > On Sat, Feb 07, 2004, M. Warner Losh wrote: > >>In message: <20040207005520.GA7132@VARK.homeunix.com> >> David Schultz 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