Date: Wed, 4 Feb 2004 23:24:22 -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: <20040205072422.GB11291@VARK.homeunix.com> In-Reply-To: <401A7FAF.7080402@freebsd.org> References: <Pine.GSO.4.10.10401300722060.7499-100000@pcnet5.pcnet.com> <20040130142603.GE99895@madman.celabo.org> <401A7FAF.7080402@freebsd.org>
index | next in thread | previous in thread | raw e-mail
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
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040205072422.GB11291>
