Date: Fri, 6 Feb 2004 16:55:20 -0800 From: David Schultz <das@FreeBSD.ORG> To: Scott Long <scottl@FreeBSD.ORG> Cc: ports@FreeBSD.ORG Subject: Re: HEADS UP: libkse -> libpthread switch Message-ID: <20040207005520.GA7132@VARK.homeunix.com> In-Reply-To: <4023C100.2090305@freebsd.org> References: <Pine.GSO.4.10.10401300722060.7499-100000@pcnet5.pcnet.com> <20040130142603.GE99895@madman.celabo.org> <401A7FAF.7080402@freebsd.org> <20040205072422.GB11291@VARK.homeunix.com> <4023C100.2090305@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040207005520.GA7132>