Hi Nicolas, In message <20080112152004.GG13250@asuka.dae.sitadelle.com>, Nicolas Baradakis <nbk@sitadelle.com> writes
David Wood wrote:
PATCH SUBMISSION - THREADING ISSUES
[...]
Firstly, for threading on FreeBSD you should just use -pthread (and not use -lpthread). There are different threading libraries available on FreeBSD; the OS does the correct thing if you just use -pthread.
-pthread vs -lpthread is a long discussion. If the "configure" script says -lpthread is supported, I think we can use it in all cases. (including FreeBSD)
I know - and I'm sorry to have to ask to complicate things further. The behaviour of -pthread on at least some FreeBSD systems is explained in: http://lists.freebsd.org/pipermail/freebsd-ports/2005-January/019345.html that is, -pthread means the thread library symbols are resolved by the linker, but it doesn't emit the DT_NEEDED for the thread library when building a shared library. At the time post this was written, 7.0 didn't exist, and I can quite believe that the different gcc and bintools versions in 7.0 changes things (see later). FreeBSD 6.x is very different to 7.x - 6.x is a gcc 3.4 based toolchain, whilst 7.x is gcc 4.2 based; most of the other bintools are similarly elderly in 6.x. That said, 6.x is still a current release series, and will need supporting for around another two years. I mention this to explain why it's quite possible for 6.x and 7.x to behave quite differently. I can't check, as I haven't got a 5.x machine to hand, but I suspect 5.x behaves the same as 6.x. A further complication with -lpthread is that FreeBSD sparc64 doesn't have libpthread, just libthr. These two threading libraries both conform (as much as really matters) to the POSIX threading ABI.
I'm unsure there's a need to make one more special case in the mainstream FreeRADIUS tree. Moreover I note that -pthread has been removed from the "pthread" manpage.
The reference to gcc -pthread on the pthread man page was because that flag used to be needed to link against a thread safe libc, libc_r. libc_r disappeared from FreeBSD 5.x, as did the note about gcc -pthread on the pthread man page. -pthread is still the way that threading is handled within FreeBSD ports - I did reference the appropriate documentation in the patch. For further confirmation, look at the value of PTHREAD_LIBS in /usr/ports/Mk/bsd.port.mk - CVSweb at http://www.freebsd.org/cgi/cvsweb.cgi/ports/Mk/bsd.port.mk I detest the complexity, but as the FreeRADIUS port maintainer, I have to live with it. Building FreeRADIUS outside a port could hit problems on at least some FreeBSD versions unless -pthread is used. When I was developing the patch, I found at least one other 'well known' application with logic to use -pthread on FreeBSD - but I can't remember which - sorry!
Secondly, it deals with the case where python is built with threads (as is now the default for python on FreeBSD). As I don't use rlm_python, I can't test whether it works after this patch, but rlm_python won't even build on FreeBSD without it.
I believe this is a problem with the python library. The linker should report the dependencies of libpython2.4.so.
I've asked a friend who is running 7.0-CURRENT and it looks OK for him:
$ ldd /usr/local/lib/libpython2.4.so.1 /usr/local/lib/libpython2.4.so.1: libutil.so.6 => /lib/libutil.so.6 (0x800c24000) libm.so.4 => /lib/libm.so.4 (0x800d32000) libthr.so.2 => /lib/libthr.so.2 (0x800e4c000) libc.so.7 => /lib/libc.so.7 (0x800632000)
If the system is showing 7.0-CURRENT, that's rather old - and python 2.5 is now the default version. Recent CURRENT is now 8.0-CURRENT, whilst 7.0 is on course for a release. [david@osmium ~]$ uname -mrs FreeBSD 7.0-BETA4 i386 [david@osmium ~]$ ldd /usr/local/lib/libpython2.5.so /usr/local/lib/libpython2.5.so: libutil.so.7 => /lib/libutil.so.7 (0x2817d000) libm.so.5 => /lib/libm.so.5 (0x2818a000) libthr.so.3 => /lib/libthr.so.3 (0x2819f000) libc.so.7 => /lib/libc.so.7 (0x28080000) This system is actually a little beyond 7.0-BETA4 - it's on the way to 7.0-RC1 level, so it's fairly recent. I shall probably rebuild it a 7.0-RC2 level when that's available. Actually this system is a VMware virtual machine - it's my 7.0 development platform. However, back on what is still the latest release: [david@titanium ~]$ uname -mrs FreeBSD 6.2-RELEASE-p9 i386 [david@titanium ~]$ ldd /usr/local/lib/libpython2.5.so /usr/local/lib/libpython2.5.so: libutil.so.5 => /lib/libutil.so.5 (0x482a6000) libm.so.4 => /lib/libm.so.4 (0x482b3000) In both cases, python was built via the lang/python25 port without any special knobs or similar configuration. Note that there's no threading library in the ldd output of 6.x, even though the library is threaded. (The lack of a libc.so dependency is because of the lack of a threading library - both libthr.so and libpthread.so depend on libc.so.)
I don't see why you would need to add -pthread to the linker command line.
Because it is quite legitimate on FreeBSD for have shared libraries - such as libpython<version>.so with thread library symbols, but without a dependency on a thread library. Without -pthread, you get an error on such systems when building rlm_python. It is for that reason that I developed the patch to the configure.in of rlm_python. It is almost certainly overkill; I suspect all it needs to do is to try -pthread on FreeBSD and not repeat all the other threading checks. Best wishes, David -- David Wood david@wood2.org.uk