Fixing -pthreads (Re: ports and -current)

Michael Edenfield kutulu at kutulu.org
Wed Sep 24 10:24:12 PDT 2003


* 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20030924/39d737e8/attachment.bin


More information about the freebsd-current mailing list