* Michael Edenfield <[EMAIL PROTECTED]> [030924 13:21]: > * 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: 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
pgp00000.pgp
Description: PGP signature
