David Wood
2007-10-23 19:10:09 UTC
(Resend with the correct email address for the mailing list - stupid me)
(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
correctly.
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.
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
gcc-4.2.3_20071011).
The net/freeradius port installs and builds OK, but radiusd doesn't
work:
/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:
/var/ports/usr/ports/net/freeradius/work/freeradius-1.1.7/src/main/.libs/
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.
OVERALL
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
problems.
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,
David
(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
***@wood2.org.uk
_______________________________________________
freebsd-***@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-***@freebsd.org"
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
(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
correctly.
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.
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
gcc-4.2.3_20071011).
The net/freeradius port installs and builds OK, but radiusd doesn't
work:
/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:
/var/ports/usr/ports/net/freeradius/work/freeradius-1.1.7/src/main/.libs/
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.
OVERALL
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
problems.
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,
David
(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
***@wood2.org.uk
_______________________________________________
freebsd-***@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-***@freebsd.org"
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de