Date: Tue, 9 Sep 2003 00:47:35 -0400 (EDT) From: Daniel Eischen <eischen@vigrid.com> To: rittle@labs.mot.com Cc: freebsd-threads@FreeBSD.org Subject: Re: Removing -pthread from gcc Message-ID: <Pine.GSO.4.10.10309090035350.18001-100000@pcnet5.pcnet.com> In-Reply-To: <200309090045.h890jDHT041330@latour.rsch.comm.mot.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 8 Sep 2003, Loren James Rittle wrote: > In article <20030906000902.GA25237@freebsd1.cimlogic.com.au>, > John Birrell<jb@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10309090035350.18001-100000>