Removing -pthread from gcc

[Daniel Eischen]

On Mon, 8 Sep 2003, Loren James Rittle wrote:

> In article <20030906000902.GA25237 at freebsd1.cimlogic.com.au>,
> John Birrell<jb at cimlogic.com.au> writes:
> 
> > If -pthread is intended as a standard FSF gcc option, then it should be mapped
> > to a NOOP for FreeBSD IMO.
> [...]
> > So a NOOP is best. Change gcc in the FSF sources when appropriate, but let
> > -current have the change now.
> 
> Ah, I could fully support this esp. if it allowed us to build shared
> libraries in ports on FreeBSD which defer selection of the thread
> library until run-time link and/or the final application link.  I know
> this works fine with one-off tweaking of a shared library's code base.
> I don't know if it is possible to do without per-library code changes.

I can't comment on this.

> In the alternative (if cleaner from ELF perspective), could we make
> plain -pthread always link weak against the prototype API for POSIX
> threads.  Then people just pre-load (aka set LD_PRELOAD , see rtld(1))
> the thread library they actually want for the run-time link.  People
> could also add -lkse, etc to early bind a concrete implementation of
> the thread library or for static link situations.

Could you explain this (small example)?  I'm not sure what you
mean by weak (references or definitions?).

We already have some pthread_foo() as weak definitions in libc
(see libc/gen/_pthread_stubs.c).  IIRC, a weak alias (macro
__weak_reference) is actually a weak definition, and a true
weak reference (#pragma weak pthread_foo) is not the same.

> Thank you guys for rethinking a bit.  As a side bonus, this would be a
> nice win over having to (re-)build the entire ports in lock-step just
> to test for best performing thread library.

We don't need to do that anyways; see libmap.conf(5).

-- 
Dan Eischen