On 24-Sep-2003 Daniel Eischen wrote: > 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! DNS problems == no outbound e-mail. :-P If gcc does want to go with a gcc-mandated -pthread option, then we should follow suit with that (and it seems that gcc might), but I don't think we need a FreeBSD-only flag if gcc doesn't mandate a -pthread option. -- John Baldwin <jhb_at_FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/Received on Wed Sep 24 2003 - 07:52:07 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:23 UTC