FreeBSD port for 2.0.0 (and a FreeRADIUS patch submission)

[David Wood]

Hi Nicolas,

In message <20080112152004.GG13250 at asuka.dae.sitadelle.com>, Nicolas 
Baradakis <nbk at 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 at osmium ~]$ uname -mrs
FreeBSD 7.0-BETA4 i386
[david at 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 at titanium ~]$ uname -mrs
FreeBSD 6.2-RELEASE-p9 i386
[david at 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 at wood2.org.uk