Date: Thu, 25 Sep 2003 01:10:37 -0400 (EDT) From: Daniel Eischen <eischen@vigrid.com> To: Loren James Rittle <rittle@latour.rsch.comm.mot.com> Cc: current@freebsd.org Subject: Re: Fixing -pthreads (Re: ports and -current) Message-ID: <Pine.GSO.4.10.10309250102560.15993-100000@pcnet5.pcnet.com> In-Reply-To: <200309250336.h8P3axl3035080@latour.rsch.comm.mot.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 24 Sep 2003, Loren James Rittle wrote:
> >I was looking through gcc last night to see how conceptually difficult
> >it would be to do something like this. But instead of a file, I was
> >thinking of this process:
> >
> >* if env("PTHREADS_LIBS") then LDFLAGS += PTHREADS_LIBS
> >* elseif fileexists("libpthread") then LDFLAGS += -lpthread
> >* elseif fileexists("libthr") then LDFLAGS += -lthr
> >* elseif fileexists("libc_r") then LDFLAGS += -lc_r
> >* else error("Threading not supported.")
>
> Hello Mike,
>
> I too thought about making -pthread an exact alias for
> env("PTHREADS_LIBS") (and, if empty, pick -lpthread or the classic
> default -lc_r). The main issue is that the FSF gcc has not accepted
> any code into the gcc driver which depends on environment variables.
What is FSF gcc policy with regard to having multiple
thread switches, ala Solaris? An alternative would be
to retain -pthread = -lc_r and switch it over to -lpthread
once sparc64 and alpha ports are done, then add a -thread
switch for -lthr if folks want similar treatment for libthr.
--
Dan Eischen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10309250102560.15993-100000>