cvs commit: src/contrib/gcc/config freebsd-spec.h
eischen at vigrid.com
Tue Sep 2 04:30:26 PDT 2003
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
> paprika# ldd /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.
More information about the cvs-src