* Ian Dowse <[EMAIL PROTECTED]> [030924 12:03]: > In message <[EMAIL PROTECTED]>, 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:
* 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.")
or whatever. At that point, simply having PTHREADS_LIBS moved into the
environment in bsd.port.mk and leaving all the ports using -pthread
alone would automatically have them support PTHREADS_LIBS. Even better,
the existing bsd.port.mk 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.
--Mike
pgp00000.pgp
Description: PGP signature
