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

From: Michael Edenfield <kutulu_at_kutulu.org>
Date: Wed, 24 Sep 2003 13:24:10 -0400
* Michael Edenfield <kutulu_at_kutulu.org> [030924 13:21]:
> * Ian Dowse <iedowse_at_maths.tcd.ie> [030924 12:03]:
> > In message <Pine.GSO.4.10.10309241029001.26896-100000_at_pcnet5.pcnet.com>, 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:
  
I should point out that my main concern here is not technical but
policy.  Right now -pthread is implemented entirely as a gcc spec as
part of LIB_SPEC.  I didn't have time to get very far so I'm not sure
how much special-case argument handling is done in gcc currently.  Would
this kind of approach, to moving the "-pthread" handling out of a
specfile and into args handling code, fly with the FSF people?

--Mike


Received on Wed Sep 24 2003 - 08:24:12 UTC

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