Date: Tue, 23 Sep 2003 16:13:11 -0400 (EDT) From: Daniel Eischen <eischen@vigrid.com> To: David Schwartz <davids@webmaster.com> Cc: Freebsd Current <current@freebsd.org> Subject: RE: Fixing -pthreads (Re: ports and -current) Message-ID: <Pine.GSO.4.10.10309231539310.12602-100000@pcnet5.pcnet.com> In-Reply-To: <MDEHLPKNGKAHNMBLJOLKAEHFGNAA.davids@webmaster.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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).
o If we support LD_PRELOAD properly, will allow us to select the
threads library without having to rebuild/relink the application.
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.
o Makes it easier to spot ports that are not PTHREAD_LIBS compliant.
Cons:
o Third party applications that use -pthread exclusively (without
linking to a threads library) will have to add a link option.
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.
--
Dan Eischen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10309231539310.12602-100000>