Re: Fixing -pthreads (Re: ports and -current)

From: Michael Edenfield <>
Date: Wed, 24 Sep 2003 13:19:49 -0400
* Ian Dowse <> [030924 12:03]:
> In message <>, Daniel
>  Eischen writes:
> >On Wed, 24 Sep 2003, Scott Long wrote:
> >> PTHREAD_LIBS is a great tool for the /usr/ports mechanism, but doesn't
> >> mean anything outside of that.
> >
> >That just meant it makes it easier to maintain ports so that
> >they are PTHREAD_LIBS compliant (they would break when linked).
> >I know it has no bearing on 3rd party stuff.
> Just to throw one further approach out on the table, below is a
> patch that makes gcc read from a file to determine what library to
> associate with the -pthread flag. It's a hack of course, and probably
> neither correct or optimal. If you want to make -pthread mean libkse,
> create an /etc/pthread.libs that looks like:

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:

* 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.")

or whatever.  At that point, simply having PTHREADS_LIBS moved into the
environment in and leaving all the ports using -pthread
alone would automatically have them support PTHREADS_LIBS.  Even better,
the existing construct could become just another pre-defined
environment variable, similar to LD_PRELOAD for the runtime linker, but
which affects the compiler/link editor instead.


Received on Wed Sep 24 2003 - 08:19:58 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:23 UTC