Date: Mon, 22 Sep 2003 07:57:34 -0400 (EDT) From: Daniel Eischen <eischen@vigrid.com> To: Scott Long <scottl@freebsd.org> Cc: Freebsd Current <current@freebsd.org> Subject: Re: Fixing -pthreads (Re: ports and -current) Message-ID: <Pine.GSO.4.10.10309220734510.2251-100000@pcnet5.pcnet.com> In-Reply-To: <3F6E8368.6000205@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 21 Sep 2003, Scott Long wrote: > Doug Barton wrote: > > Errrr... I'm not sure this is an optimal solution. There is an awful > > lot of software out there which expects -pthread to "just work." > > Wouldn't it make more sense to default it to one thing or the other, > > then make it configurable (isn't this what libmap.conf is supposed to > > help with)? > > > > Doug > > > > I have to agree with this. '-pthread' seems to have taken on the > meaning of 'turn on whatever magic makes the pthreads library work'. > The application writer is allowed to focus on the application, not > the FreeBSD-specific threading library options. The user is allowed > to compile a third-party app without having to worry about the > FreeBSD-specific threading library options. Everyone wins. Most everyone that writes threaded applications and runs on multiple platforms knows that most thread libraries are called libpthread and are linked to with -lpthread. Once we rename libkse to libpthread, the problem largely goes away. The porter, or configure script, will find libpthread and all should be fine. > If we take the stand that any software that uses '-pthread' is broken > and should be fixed by the author, it will make FreeBSD wildly > unpopular. If we take the stand that the only sactioned way to > compile a third-party app in FreeBSD is via the ports system, then > FreeBSD will become much less usable. There will be a libpthread and -pthread will be NOOP'd. It should be a very familiar environment. > I've tried to stay silent on this issue in hopes that it would work > itself out, but I'm not quite sure that it is. Making FreeBSD harder > to use and harder to program for in the name of pendanticy is not the > best direction. As I've said in a previous email, Solaris doesn't have -pthread and it hasn't seemed to cause any problems. If you are going to have -pthread (libpthread), -thread (libpthread1:1), -thr (libthr), -uthread (libc_r), this is no different than making them the appropriate link arguments. There should be very little problem for 3rd party applications. -pthread won't cause an error. If there is any problem, it will be on the link command and it should be very obvious that a threading library wasn't pulled in. Since a libpthread will be present on the system, it's pretty much a no-brainer how to fix the problem. This is not like we're changing kernel or library interfaces. I think folks are making a bigger deal out of it than it really is. -- Dan Eischen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10309220734510.2251-100000>