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

[Daniel Eischen]

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