Date: Fri, 5 Sep 2003 19:47:01 -0400 (EDT) From: Daniel Eischen <eischen@vigrid.com> To: Loren James Rittle <rittle@latour.rsch.comm.mot.com> Cc: freebsd-threads@FreeBSD.org Subject: Re: Removing -pthread from gcc Message-ID: <Pine.GSO.4.10.10309051914370.1042-100000@pcnet5.pcnet.com> In-Reply-To: <200309052235.h85MZoRF015386@latour.rsch.comm.mot.com>
next in thread | previous in thread | raw e-mail | index | archive | help
John Birrell CC'd to help explain the history of -pthread. On Fri, 5 Sep 2003, Loren James Rittle wrote: > Hi Daniel, > > (Sorry, I read -current, -stable, -hackers to try to track changes to > the system compiler. A private request came to me to make a change to > the FSF tree to mirror this change.) > > Could you please explain this line a bit more: > > > If [-pthread] left in and we try to link with > > libpthread,libkse,libthr, etc, we will end up with ports that link > > to one of those libraries _and_ libc_r. Just try copying libkse or > > libthr to libpthread _without_ changing PTHREAD_LIBS (so you still > > use libc_r) and rebuilding X or KDE. > > You have raised a red herring. It may be true, but there has to be a > better fix than breaking a 5+ year convention. If a user adds -lkse > to CCFLAGS and sets the ports threads package to -lc_r, then the same > problem ensues. Are you sure that this root problem is actually > caused by a compiler supporting -pthread (perhaps the ports system > should just stop using -pthread since was a pure alias for -lc_r > before your patch)? Other systems support -pthread in gcc and have an > -lpthread yet do not display the issue you describe. Why is FreeBSD > special in having that problem? Perhaps -pthread should be mapped to > -lpthread instead of -lc_r (upon a flag day, etc.), if that could help > the situation. The problem is that -pthread maps to one threads library, and we have multiple threads libraries from which to choose. We have libc_r, libkse (M:N mode), libkse (1:1 mode), and libthr. -pthread arose (in FreeBSD anyways) because you couldn't link to both libc and libc_r in FreeBSD-[34]. In FreeBSD-5+, we don't need -pthread. In other words, -pthread was replaced by -lthr, -lkse11, -lkseMN, or -lc_r. The one dimensional -pthread doesn't serve us any longer. I would have less of an objection if -pthread were kept in but made a NOOP. > Please do not use a current shortcoming in ports(5) to kill a > portability feature of gcc. A claim has been floated that -pthread is > not standard. I tell you that is not the intention of the FSF gcc > team, even if it is poorly documented. Since gcc 3.0 (some have been > added post 3.0 release over time): > > -pthread is supported on Linux (I believe actually copied from FreeBSD > even though they never had the switch -lc to <replacement library> issue). > "Everyone" in the BSD world claims to hate autoconf, libtool; yet > removal of this -pthread feature leads away from emerging > standardization in gcc not towards it. Such balkanization will > actually require more special cases for FreeBSD in such tools not less. Most of the autoconfs I have seen check for -lpthread, and -lthread, even -lc_r. Once FreeBSD renames libkse(M:N) to libpthread, autoconf should be unbroken, probably libtool also. We could have thrown the switch from libkse to libpthread at the same time as -pthread was removed from our repo, but (mostly) I didn't do it so that "shortcoming in ports" could be easily found and fixed. > I will fix the FSF documentation for gcc, if you were led astray by > the explicit references to AIX but none other. > > If you are unmoved by my line of argument, then I hereby promise to > commit the change such that it hits the FSF gcc 3.4 release. Upon > review, I can't honor any request to make it hit the FSF gcc 3.3.2 > release since we don't revoke features in point releases in that tree. > > Thank you for considering these words. BTW, wouldn't it be cooler > if (example only): > > -pthread (whatever the system default) > -pthread=1 (1 process, aka -lc_r) > -pthread=1:1 (1 process per thread, aka -lthr) > -pthread=M:N (M threads in N processes, aka -lkse) > -pthread=late/weak (perhaps not good ELF form, link against a stub to > which all POSIX thread libraries on FreeBSD must conform, do not > record the dependency ala FreeBSD4 default for -lc; or that does it in > a weak manner en mass such that binding is deferred to the final > selection made at a final link time) That's a lot better :-) The only problem is that we have 2 different libraries that offer 1:1... I would not object to this approach, but I would like to temporarily make -pthread (without args) either a NOOP or an error in our tree to help correct "shortcoming in ports". > I suspect that late/weak could be quite useful for building ports and > allowing the final application link to select the thread > implementation via the final specification. BTW, I'm the libstdc++-v3 > maintainer that did a lot of the threading improvements in the FSF > tree (basically made threaded-C++ work as well or better than Linux > IMHO ;-) so I hope I'm a stakeholder here. When built in the FSF tree > (and I suspect the FreeBSD system tree), libstdc++-v3 is setup to do > late binding as I'm proposing as a generic feature above. > > On FreeBSD 4-STABLE, 5-CURRENT similar: > > ; ldd /usr/local/beta-gcc/lib/libstdc++.so.6: > libm.so.2 => /usr/lib/libm.so.2 (0x28177000) > libgcc_s.so.1 => /usr/local/lib/libgcc_s.so.1 (0x28193000) > > ; nm /usr/local/beta-gcc/lib/libstdc++.so.6 |grep pthread > 00058bc4 T _ZNSt12__basic_fileIcEC1EPP13pthread_mutex > 00058bb0 T _ZNSt12__basic_fileIcEC2EPP13pthread_mutex > w pthread_create > w pthread_getspecific > w pthread_key_create > w pthread_mutex_lock > w pthread_mutex_unlock > w pthread_once > w pthread_setspecific > > It is possible that there are unknown snags with this approach. > E.g. The weakness property was applied at the source level of the > library. It may not be possible to make a library that claims to > export various symbols yet are really weak placeholders. I am not an > ELF expert; I only know enough to be dangerous... ;-) I suppose kan might have something to say about this. -- Dan Eischen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10309051914370.1042-100000>