On Tue, 23 Sep 2003, David Schwartz wrote:
On Mon, 22 Sep 2003, David Schwartz wrote:
No. There are other environments that don't have -pthread though.
So now FreeBSD will support a flag that numerous other platforms support, however it will support it differently from every other platform. On every other platform I know of where '-pthread' does anything other than generate an error, it causes the compiler to conform to the pthreads standard. FreeBSD will be the only platform that knows what '-pthread' is but doesn't do the right thing when it gets it.
Isn't it good to have one flag that, on every platform that supports it, gives you whatever's needed to get the default pthreads implementation to work? And isn't that what '-pthread' was supposed to be for?
Why do you want to shoehorn -pthread onto us when it is not a good fit?
Then don't support it. Return an error and nothing will break.
You have the support of the threads guys here, including jb. But we've been pushed the other way.
However, I'd also suggest making it easy for people to set '-pthread' to give whatever pthreads library they think is the most sensible default for their installation.
You can't make it variable.
I'm running out of energy here. None of the threads guys want -pthread and if forced on them would prefer it to be a NOOP. I am trying very hard not to be biased towards one threads library over another, and having -pthread automatically link to libpthread gives preference to it over libthr (or libthread (KSE in 1:1 mode) or libc_r).
Pros: o Allows us to define macros common to all the threads libraries. o Allows shared libraries (Qt, GTK, OpenGL, etc) to be built that are not dependent on a particular threads library, but will use whatever threads library the application uses (i.e., you want mplayer to use libpthread and ogle to use libthr).
I'm a big advocate of using libmap to deal with this.
o If we support LD_PRELOAD properly, will allow us to select the
threads library without having to rebuild/relink the application.
I'm a big advocate of using libmap to deal with this.
o Doesn't break applications that use both -pthread and -l<threadlib>.
We've been able to link both libc_r and libc in -current for well
over 2 years. Indeed, if you build KDE and X with libpthread installed,
you will see binaries that are linked to both libc_r and libpthread.
I can't see how this behaviour would not be considered a bug, if it is indeed true. Are you saying that there are packages out there that will detect both -lpthread and -pthread and attempt to use both on the compilers and linker lines?
o Makes it easier to spot ports that are not PTHREAD_LIBS compliant.
PTHREAD_LIBS is a great tool for the /usr/ports mechanism, but doesn't mean anything outside of that.
I suspect that the majority of users won't give a hoot about the
mechanics of all of this as long as it Just Works. The more sophisticated users that want to mix/match threading libraries can be
expected to exert a little more effort and learn the tools like libmap,
etc.
Cons: o Third party applications that use -pthread exclusively (without linking to a threads library) will have to add a link option.
This is where I have the biggest problem. I firmly believe that it is incorrect for you to downplay this scenario, and it appears that others agree too. This is the case that will give us the black eye with users and developers that want things to Just Work.
I understand that folks want to wave their hands and say "just make -pthread work and do whatever it needs to". I'm like that myself. I just don't think it's a good idea.
I'm unclear why it is impossible to do this. The whole point of -pthread is to make it Just Work. We have complete control over how
we make that happen. Why is it impossible to make -pthread honor
PTHREAD_LIBS? Why is it impossible to fix ports that try to
mix pthread schemas?
Scott
_______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
