Date: Wed, 24 Sep 2003 16:12:34 +1000 From: John Birrell <jb@cimlogic.com.au> To: Stijn Hoop <stijn@win.tue.nl> Cc: Kris Kennaway <kris@obsecurity.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>