Apparent devel/libtool problems with gcc 4.2, as seen with net/freeradius

David Wood david at
Tue Oct 23 12:26:41 PDT 2007

(ade@ cc'd as maintainer of devel/libtool)

Dear all,

The upcoming ports freeze has focussed my mind on this problem. I was 
hoping to wait until ports/117160 was committed which tidies up various 
issues with the net/freeradius port I maintain first. However, the ports 
freeze is getting close, the problems mentioned below show just as well 
in the version of the port in the tree, and this may affect other ports, 
which is why I wanted to mention it now.

PROBLEM 1: failure to link radiusd on 7.0 amd64

Various people (stas@ and pav@ particularly) have been in correspondence 
with me about the build problem with net/freeradius on 7.0 amd64. The 
problem isn't a lack of -fPIC; the port already deals with that 

The port seemed to stop building on amd64 when 7-CURRENT (as it was 
then) was switched to gcc 4.2. It's now been marked BROKEN on 7.0 amd64, 
but the problem on the portsmon runs was in the libtool --mode=link -o 
radiusd step for the main radiusd binary:

/usr/bin/ld: /usr/lib/crt1.o: relocation R_X86_64_32 can not be used 
when making a shared object; recompile with -fPIC
/usr/lib/crt1.o: could not read symbols: Bad value

In the discussion that we had then by private mail, one of the 
committers agreed with my suggestion that this may be a toolchain 

PROBLEM 2: unexecutable radiusd on 6.2 i386 when built with gcc 4.2

Subsequently, I tried building the net/freeradius port with
make USE_GCC=4.2 install on my 6.2-RELEASE-p8 i386 box (at this time, 
I'm one version of lang/gcc42 out of date - my box is still on 

The net/freeradius port installs and builds OK, but radiusd doesn't 

/usr/local/sbin/radiusd: cannot execute binary file

If you go into the src/main directory in the work directory, radiusd 
there is a script. It won't execute if you built the port with gcc 4.2 - 
instead you'll get an error along the lines of:

radiusd: 1: Syntax error: "(" unexpected

The real radiusd binary is 'hiding' in .libs; if you try to run 
.libs/radiusd you get the previous "cannot execute binary file" error.

At this point, if you look at the typescript from when you built the 
port, and repeat the libtool --mode=link step for radiusd with gcc 
(3.4.6) rather than gcc42, the radiusd binary works correctly! This is 
exactly the same step that was playing up on 7.0 amd64, though it's 
broken here in a vastly different way.

For testing purposes, running radiusd with -X so that it doesn't 
daemonise is probably the easiest. If it makes any difference (which I 
doubt), I typically build the port with LDAP and MYSQL enabled (default 
versions in both cases) for my environment.

This problem with gcc 4.2 on FreeBSD 6.2-RELEASE i386 is repeatable with 
FreeRADIUS 2.0.0-pre2 (for this port, see ports/117160 and ports/117161 
- you need to apply both patches to net/freeradius from the ports tree).

I'm pretty sure I tried building using the libtool included with 
FreeRADIUS rather than the devel/libtool port, and I got the same 
results - though, unfortunately, I didn't make any notes to remind me 
exactly what I did.


I have tried looking at what libtool is doing, but it's far too 
complicated for me to sort out easily, as a relative novice to all 
things libtool. What I can say is that libtool seems to carry out a 
*very* different set of steps between the two gcc versions.

I live in hope that there may just be one problem here with two 
different sets of symptoms - but it could just as easily be two separate 

Help would be *greatly* appreciated. If this does turn out to be a 
libtool problem, there may be more problems are lurking with libtool and 
gcc 4.2. I believe that this is not to do with anything in the ports of 
the FreeRADIUS source, though if someone can prove me wrong and explain 
why, I'll be just as happy.

linimon@ is, I believe, aware that I think there may be a problem with 
libtool. At the very least, I'd urge maintainers to check that any 
software that uses libtool not only builds with gcc 4.2, but works when 
built with gcc 4.2 as well.

Best wishes,

(net/freeradius maintainer)

PS: I'm aware of ports/117262 thanks to edwin's script - I am working on 
a major upgrade to the rc.d script with just one problem now left to 
fix. I will hopefully have a patch ready to submit shortly.
David Wood
david at

More information about the freebsd-ports mailing list