Re: FreeBSD port for 2.0.0 (and a FreeRADIUS patch submission)
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 (0x2808) 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
Re: FreeBSD port for 2.0.0 (and a FreeRADIUS patch submission)
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'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. 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) I don't see why you would need to add -pthread to the linker command line. -- Nicolas Baradakis - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
FreeBSD port for 2.0.0 (and a FreeRADIUS patch submission)
Hi all, In message [EMAIL PROTECTED], Alan DeKok [EMAIL PROTECTED] writes David Wood wrote: I am about to start working on an update of that port to 2.0.0 - and it will likely be renamed net/freeradius2 at the same time, as it's no longer a development version. My part of this isn't likely to take too long (hopefully 12 hours to submit the FreeBSD PR barring unexpected problems as I start to work on it this evening), but getting it committed to the FreeBSD ports tree will take longer. Sounds good to me. I was a little bit slower than I'd hoped, but I've now submitted FreeBSD PR ports/119582 to create the net/freeradius2 port (and get rid of the net/freeradius-devel port which was pretty much stillborn this time round). The PR can be viewed at: http://www.freebsd.org/cgi/query-pr.cgi?pr=119582 If you want a copy of the port now, make a copy of an up to date (that's important!) /usr/ports/net/freeradius outside /usr/ports, apply the patch in the PR to your copy, uninstall your current FreeRADIUS (follow the advice in the suggested entry for /usr/ports/UPDATING please), then 'make config clean install' should give you a working FreeRADIUS 2.0.0. Whilst this may not be exactly the form that the port is committed as, it is working fine on my system. PATCH SUBMISSION - THREADING ISSUES I'd be grateful if someone from the FreeRADIUS team could look over files/patch-pthread for inclusion in FreeRADIUS itself. http://www.freebsd.org/cgi/cvsweb.cgi/ports/net/freeradius-devel/files/p atch-pthread?rev=1.1 is a version of the patch that should apply cleanly against 2.0.0. If you want a 1.1.7 version, look at the same file in freeradius rather than freeradius-devel. It would be useful if both 1.1 and 2.0 could be patched in this way. The patch solves two problems. 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. 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. FREEBSD PORTING ISSUES FOR 2.0.0 When creating the 2.0.0 port, I made a couple of decisions that may be unpopular amongst embedded system users. Firstly, NOPERL is now only available as a knob, and has been removed from the options. It was a horrid hack as I've explained in some new Makefile comments. If you really need it use make -DWITH_NOPERL - but building FreeRADIUS without perl available is not recommended. I've also chosen to depend unconditionally on python for 2.0.0, and always build rlm_python. Of course, I could configure --without-rlm_python. The problem is that, at the moment, the FreeBSD ports system doesn't allow a conditional dependency on python without the nasty hack previously used when the experimental option was selected. The hack causes portlint to declare the port has a FATAL error, and I didn't think I'd get away with moving it elsewhere in the Makefile. bsd.options.mk will solve this problem. When it's available, ports will be allowed to act on their options before including any of the bsd.port.mk stuff, which means all USE options can be conditional on options. Unfortunately, bsd.options.mk can't be used yet as the necessary OS support only exists in the as yet unreleased FreeBSD versions 6.3 and 7.0. At minimum I think it will need passing the End of Life date of the entire 5.x branch and the subsequent ending of ports support for 5.x, as well as passing the End of Life date for 6.2 before ports are allowed to use bsd.options.mk. This could all happen on or shortly after 31 May 2008. Porting is a bit of a nightmare at the moment, as you have to support 5.x, 6.x, 7.x and the development 8.x tree. There are no plans for another 5.x release, and I'm one of those that was no great fan of 5.x. Anyone who has a machine running any version of FreeBSD earlier than 6.x is encouraged to consider an upgrade to 7.0-RELEASE when that is available, hopefully within the next two months. If 7.0-RELEASE is too bleeding edge for you, try 6.3-RELEASE (also currently in RC) instead. I could be persuaded to revisit the NOPERL stuff, though I can only really see two ways to do this properly. One is a conditional patch configure.in to disable all the perl tests, which is a maintenance nightmare for me. The other is to persuade the FreeRADIUS developers included a configure flag to disable perl globally. The final option was to go back to the messy 1.x situation; my reading of the configure.in is that the absence of perl merely generates a warning and that disabling rlm_perl is enough. There is the risk of strange brokenness in following the messy route if FreeRADIUS's dependency on perl ever changes; most
