From owner-cvs-src@FreeBSD.ORG Tue Sep 2 04:30:26 2003 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 04C4016A4BF; Tue, 2 Sep 2003 04:30:26 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 70D4E43FE0; Tue, 2 Sep 2003 04:30:24 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h82BUNtp026512; Tue, 2 Sep 2003 07:30:23 -0400 (EDT) Date: Tue, 2 Sep 2003 07:30:23 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Robert Watson In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: cvs-src@freebsd.org cc: src-committers@freebsd.org cc: Scott Long cc: cvs-all@freebsd.org Subject: Re: cvs commit: src/contrib/gcc/config freebsd-spec.h X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: deischen@freebsd.org List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2003 11:30:26 -0000 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