cvs commit: src/contrib/gcc/config freebsd-spec.h

[Robert Watson]

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 at fledge.watson.org      Network Associates Laboratories