Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 24 Sep 2003 16:12:34 +1000
From:      John Birrell <jb@cimlogic.com.au>
To:        Stijn Hoop <stijn@win.tue.nl>
Cc:        Michael Edenfield <kutulu@kutulu.org>
Subject:   Re: Initial list of ports that fail due to -pthread
Message-ID:  <20030924061234.GC44314@freebsd1.cimlogic.com.au>
In-Reply-To: <20030924060135.GB95116@pcwin002.win.tue.nl>
References:  <20030924053413.GA28722@wombat.localnet> <Pine.GSO.4.10.10309240137330.28336-100000@pcnet5.pcnet.com> <20030924060135.GB95116@pcwin002.win.tue.nl>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Sep 24, 2003 at 08:01:35AM +0200, Stijn Hoop wrote:
> - fix all ports to respect PTHREAD_LIBS _ON THE LINKING STAGE_ (so no
>   global search & replace, for it shouldn't be used in compile command lines)
> - keep '-pthread' as a compiler option, which maps to a NOOP for compiling
>   and '-lpthread' (aka libkse) for linking
> - set PTHREAD_LIBS to the default value of -pthread
> - allow PTHREAD_LIBS to be set to something other, e.g. '-lthr', in
>   /etc/make.conf (or the make command line)
> 
> What is the problem with this approach? You get both a 'standard' -pthread
> knob, _and_ the ability to select your threads library using ports.
> Third party apps that use -pthread will work. The only case in which some
> work has to be done by a FreeBSD user is when they want to link a non-ported
> third-party app with a library other than libpthread (libkse).

I think you are probably right. We need to remember that third party apps
fit best in ports if they work out of the box without patches and twiddles.
We probably should only rely on PTHREAD_LIBS for the non-standard cases where
people want to be clever.

-- 
John Birrell



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030924061234.GC44314>