Date: Tue, 2 Sep 2003 00:31:48 -0400 (EDT) From: Robert Watson <rwatson@freebsd.org> To: Scott Long <scottl@freebsd.org> Cc: cvs-all@freebsd.org Subject: Re: cvs commit: src/contrib/gcc/config freebsd-spec.h Message-ID: <Pine.NEB.3.96L.1030901232042.73191C-100000@fledge.watson.org> In-Reply-To: <3F52A976.4060708@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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).
(1) Allow an administrator to express per-application dependency on an
explicitly selected threading library.
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.
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
robert@fledge.watson.org Network Associates Laboratories
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1030901232042.73191C-100000>