Date: Wed, 10 Sep 2003 16:41:01 -0400 (EDT) From: Daniel Eischen <eischen@vigrid.com> To: Michael Edenfield <kutulu@kutulu.org> Cc: netchild@freebsd.org Subject: Re: Quo vadis, -CURRENT? (recent changes to cc & compatibility) Message-ID: <Pine.GSO.4.10.10309101632230.23731-100000@pcnet5.pcnet.com> In-Reply-To: <20030910201600.GA37408@wombat.localnet>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 10 Sep 2003, Michael Edenfield wrote:
> * David O'Brien <obrien@FreeBSD.org> [030910 15:33]:
> > On Wed, Sep 10, 2003 at 12:41:41PM -0400, Michael Edenfield wrote:
> > > gnome2 depends on gnomemedia2.
> > > gnomemedia2 depends on gstreamer-plugins.
> > > gstreamer-plugins fails because ARTSD_FLAGS in several dozen Makefiles
> > > includes -pthread.
> >
> > This is being worked on from the compiler stand point.
>
> Which is the main reason I didn't do a pr on it. But from reading other
> parts of the thread, it seems that ports should not be using -pthread
> anyway... would it be worthwhile to submit patches to remove -pthread
> (and, for that matter, -lpthread and other variants) in favor of
> ${PTHREAD_LIBS} regardless of wether `cc -pthread` is an error or a
> no-op, or some magical auto-thread-library-selector?
Yes, ${PTHREAD_LIBS} should be used, except perhaps for
ports that are libraries. Under the proposed scheme,
libraries could be weakly linked to a stub pthread
library (or even pthread stubs in libc I suppose). Then
when an application (strongly linked to _a_ threads
library) loads/references the library, that library
uses the same threads library that the application is
linked to.
But threaded executables still need to be linked to
some threads library, and that should be selectable
via PTHREAD_LIBS.
--
Dan Eischen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10309101632230.23731-100000>