Date: Tue, 2 Sep 2003 07:30:23 -0400 (EDT) From: Daniel Eischen <eischen@vigrid.com> To: Robert Watson <rwatson@freebsd.org> Cc: cvs-all@freebsd.org Subject: Re: cvs commit: src/contrib/gcc/config freebsd-spec.h Message-ID: <Pine.GSO.4.10.10309020722030.25164-100000@pcnet5.pcnet.com> In-Reply-To: <Pine.NEB.3.96L.1030901232042.73191C-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 2 Sep 2003, Robert Watson wrote: > On Sun, 31 Aug 2003, Scott Long wrote: > > > Daniel Eischen wrote: > > > deischen 2003/08/31 15:38:52 PDT > > > > > > FreeBSD src repository > > > > > > Modified files: > > > contrib/gcc/config freebsd-spec.h > > > Log: > > > Remove -pthread as a compiler option. It was deprecated 2.5 years > > > ago, but not removed. > > > > What is the consequence of this on ports/? I'm very much in favor of > > this change, but I'm wondering if more safety belts are needed. Also, > > are there any consequences on the doc/ and www/ areas? > > The effect I'm most interested in "getting right" at this point has to do > with library dependencies in third party applications. Right now, when we > build QT on FreeBSD, the resulting library has an explicit dependency on > libc_r: > > paprika# ldd /usr/X11R6/lib/libqt-mt.so > /usr/X11R6/lib/libqt-mt.so: > libmng.so.1 => /usr/local/lib/libmng.so.1 (0x287bc000) > ... > libc_r.so.5 => /usr/lib/libkse.so.1 (0x28b06000) > ... > > On my notebook, I use libmapl.conf to rewrite the dependency such that KSE > is used. I think it's very important that we avoid a situation where, if > there are potential future changes in threading libraries, we find > binaries dependent on various threading libraries. I'd like to see a > dependency on a single name, with a way to substitute that name. I.e., > all libraries dependent on a threading library, unless explicitly > configured otherwise, should be linked against a single common library. > > Otherwise, if we wipe out libc_r someday, or remove the 1:1 version of KDE > and decide M:N is the one true way, we'll leave users up a creek. My > leaning is to support at least two approaches to all this: > > (1) Allow the administrator to express a system-wide default for which > thread library makes the most sense for the system (perhaps based in > part on architecture and thread support level). This is what PTHREAD_LIBS is for. The system administrator edits /etc/make.conf and changes it from whatever is in bsd.ports.mk. Or bsd.ports.mk is changed to know that libfoo is to be used on ia64, while libbar is used on other archs. > (1) Allow an administrator to express per-application dependency on an > explicitly selected threading library. The administrator either sets PTHREAD_LIBS in the environment before building the port or uses /etc/libmap.conf. > This would be supported by going with "-lpthread" and related notions, but > is less well by linking to libkse, libthr, et al, directly, as that > introduces an explicit dependency on a specific package. However, a > potentially confusing element here is that there's an intention to rename > libkse to libpthread, which I guess I'd prefer to think of more as a > linking name so that we retain flexibility on the threading library, as > opposed to the name of an actual library, even if the default mapping is > always to libkse. Having a link is no different than setting PTHREAD_LIBS appropriately (assuming ports is cleaned up a bit, which is part of what I'm trying to help accomplish with removing the -pthread compiler option). If you want One-True-Link, please use somthing other than libpthread. I don't support this though. -- Dan Eischen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10309020722030.25164-100000>