Hi Nicolas,
In message <[EMAIL PROTECTED]>, Nicolas
Baradakis <[EMAIL PROTECTED]> 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.
[EMAIL PROTECTED] ~]$ uname -mrs
FreeBSD 7.0-BETA4 i386
[EMAIL PROTECTED] ~]$ 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:
[EMAIL PROTECTED] ~]$ uname -mrs
FreeBSD 6.2-RELEASE-p9 i386
[EMAIL PROTECTED] ~]$ 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
[EMAIL PROTECTED]
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
