Date: Mon, 8 Sep 2003 19:45:13 -0500 (CDT) From: Loren James Rittle <rittle@latour.rsch.comm.mot.com> To: freebsd-threads@FreeBSD.org Cc: jb@FreeBSD.org Subject: Re: Removing -pthread from gcc Message-ID: <200309090045.h890jDHT041330@latour.rsch.comm.mot.com> In-Reply-To: <20030906000902.GA25237@freebsd1.cimlogic.com.au> (message from John Birrell on Sat, 6 Sep 2003 10:09:02 %2B1000) References: <200309052235.h85MZoRF015386@latour.rsch.comm.mot.com> <Pine.GSO.4.10.10309051914370.1042-100000@pcnet5.pcnet.com> <20030906000902.GA25237@freebsd1.cimlogic.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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. 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. 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. Regards, Loren
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200309090045.h890jDHT041330>