Date: Tue, 23 Sep 2003 12:03:41 -0400 (EDT) From: Daniel Eischen <eischen@vigrid.com> To: Loren James Rittle <rittle@latour.rsch.comm.mot.com> Cc: current@freebsd.org Subject: Re: Fixing -pthreads (Re: ports and -current) Message-ID: <Pine.GSO.4.10.10309231158080.26272-100000@pcnet5.pcnet.com> In-Reply-To: <200309231545.h8NFjMVV027788@latour.rsch.comm.mot.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 23 Sep 2003, Loren James Rittle wrote: > > I'm all for removing it, but our FSF GCC maintainer thought > > it better to make it a NOOP. We're just going by his advice. > > I agreed that making -pthread == NOOP was probably better than the > ~Sept 5 -CURRENT system compiler however that was not my full advice. > > In my view (and thus my advice), it is the stated collective opinion > of the FSF gcc development team that -pthread should exist for all gcc > ports which support POSIX threads. This is true even if not well > documented. It would be best if adding the switch actually implied > everything to support threads. > > If adding the -pthread switch is a NOOP to gcc but users could later > add (e.g.): LD_PRELOAD=libc_r.so (or one of the newer choices) and not > break anything, then I think that would be fully acceptable and meet > the specification of the switch. This would be very cool in that you > could test/run against multiple thread libraries without a re-link. Yes, and I agree. If someone were to tell me how to implement that, I would do it. If it is just a matter of adding some missing pthread interfaces as stubs to libc, then it is pretty simple. > If adding the -pthread switch is a NOOP to gcc but users must also add > -lc_r (or one of the newer choices) for correct operation, then I > think making it a NOOP is a bad idea and I attempted to state so. Well, if they don't use LD_PRELOAD=libc_r.so or whatever and try to run the application, it isn't going to work very well using pthread stubs. -- Dan Eischen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10309231158080.26272-100000>