Date: Fri, 06 Feb 2004 09:29:52 -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: <4023C100.2090305@freebsd.org> In-Reply-To: <20040205072422.GB11291@VARK.homeunix.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4023C100.2090305>