Date: Wed, 24 Sep 2003 11:11:44 -0400 (EDT) From: Daniel Eischen <eischen@vigrid.com> To: John Baldwin <jhb@freebsd.org> Cc: Dan Naumov <dan.naumov@ofw.fi> Subject: RE: Fixing -pthreads (Re: ports and -current) Message-ID: <Pine.GSO.4.10.10309241111040.26896-100000@pcnet5.pcnet.com> In-Reply-To: <XFMail.20030924091322.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 24 Sep 2003, John Baldwin wrote: > > On 23-Sep-2003 Dan Naumov wrote: > > On Tue, 2003-09-23 at 23:25, Dan Naumov wrote: > >> On Tue, 2003-09-23 at 23:13, Daniel Eischen wrote: > >> > I understand that folks want to wave their hands and say "just make > >> > -pthread work and do whatever it needs to". > >> > >> I am one of those folks as well. As an end-user, I am not interested in > >> hacking around the source of 3rd-party applications that use -pthread > >> when compiling them from source myself. Not in the slightest. This is > >> BAD BAD BAD for usability. > >> > >> Sincerely, > >> Dan Naumov > > > > I also believe that a question has to be asked, what do the -core and > > -arch people think of all this ? I think that they should have the final > > say in the matter. > > I think having a magic option to gcc that translates to 'link with the > foo library' is rediculous. What's next, a gcc -math to get the math > functions in libm? The fact that functions live in libraries and that > to get access to said functions you link with said libraries has been > the practice on Un*x for longer than I've been alive. Please, people, > let the -pthread hack die and just use -l<mumble thread library>. > I think any FreeBSD-specific -pthread bits should just be removed > and have the compiler complain about a bogus option. If gcc chooses > to have a machine independent -pthread (or -thread) to turn on TLS or > some such, that's great and all, but that would be gcc code, not > FreeBSD-specific code. Where were you a few days ago! -- Dan Eischen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10309241111040.26896-100000>