From owner-freebsd-current@FreeBSD.ORG Fri Feb 6 16:55:28 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 AEDE516A4CE; Fri, 6 Feb 2004 16:55:28 -0800 (PST) Received: from VARK.homeunix.com (adsl-68-122-2-18.dsl.pltn13.pacbell.net [68.122.2.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 73F6543D41; Fri, 6 Feb 2004 16:55:24 -0800 (PST) (envelope-from das@FreeBSD.ORG) Received: from VARK.homeunix.com (localhost [127.0.0.1]) by VARK.homeunix.com (8.12.10/8.12.10) with ESMTP id i170tLTJ007466; Fri, 6 Feb 2004 16:55:21 -0800 (PST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.homeunix.com (8.12.10/8.12.10/Submit) id i170tKvd007465; Fri, 6 Feb 2004 16:55:20 -0800 (PST) (envelope-from das@FreeBSD.ORG) Date: Fri, 6 Feb 2004 16:55:20 -0800 From: David Schultz To: Scott Long Message-ID: <20040207005520.GA7132@VARK.homeunix.com> Mail-Followup-To: Scott Long , "Jacques A. Vidrine" , deischen@FreeBSD.ORG, ports@FreeBSD.ORG, current@FreeBSD.ORG References: <20040130142603.GE99895@madman.celabo.org> <401A7FAF.7080402@freebsd.org> <20040205072422.GB11291@VARK.homeunix.com> <4023C100.2090305@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4023C100.2090305@freebsd.org> cc: "Jacques A. Vidrine" cc: deischen@FreeBSD.ORG cc: current@FreeBSD.ORG cc: ports@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 00:55:28 -0000 On Fri, Feb 06, 2004, Scott Long wrote: > David Schultz wrote: > >On Fri, Jan 30, 2004, Scott Long wrote: > > > >>Jacques A. Vidrine wrote: > >> > >>>On Fri, Jan 30, 2004 at 07:34:02AM -0500, Daniel Eischen wrote: > >>> > >>> > >>>> Until > >>>> the ports system is updated to handle this change, it is > >>>> recommended that folks install an /etc/libmap.conf(5) that > >>>> maps libc_r to libpthread. > >>> > >>> > >>>Why, exactly? (curious) > >>> > >>>IMHO it is unacceptable to require /etc/libmap.conf to exist. I know > >>>this is temporary, but I hope it is *really* temporary. > >>> > >>>Cheers, > >> > >>We certainly are not going to ship 5.3 like this. However, given that > >>HEAD is a development branch and that change does not happen > >>instantly, I think that this fine for now. > > > > > >Actually, installing a libmap.conf mapping libc_r to libpthread by > >default in 5.3 might be *less* painful than the alternative. > >Otherwise, an application compiled after the change that links > >against a multithreaded library compiled before the change might > >depend on both libc_r.so and libpthread.so, which would inevitably > >cause things to go wrong at runtime. Without a libmap.conf, it > >would seem that users would be forced to upgrade all of their > >applications and libraries that depend on libc_r simultaneously. > > > > > >P.S. In grepping through the next few days of -CURRENT, which I > > haven't read yet, it seems that someone has already been > > bitten by this problem. See Subject: wxgtk build error > > libpthred related > > > > That's an interesting viewpoint that might be good to consider. > However, what's really going to bite people is the cases where > half of an app has libc_r statically compiled in, and the other > half has it dynamically compiled in. libmap.conf is useless for > that situation except to remap everything back to the static > library. So, it's probably best right now to reinforce that > recompiling/portupgrading is the best course of action. 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. In any case, all of the applications and libraries from ports that I use depend on libc_r dynamically, so mapping libc_r to libpthread in libmap.conf ``just works'', as far as I can tell.