Building FreeRADIUS on HP-UX B.11.31 ia64 (gcc, 32bit)
Hello, There are 2 problems with HP-UX build (I use GNU gcc and native ld): 1. ld options '+b <libdir>' are passed without '-Wl,' prefix directly to gcc (not to ld):
gcc -shared -Wl,+h -Wl,rlm_acctlog-2.1.12.so -Wl,+nodefaultrpath -o .libs/rlm_acctlog-2.1.12.so .libs/rlm_acctlog.o +b /comptel/ilink/src/freeradius-server-2.1.12/src/lib/.libs:/comptel/ilink/xxxxxxxxxxxxxxxx32/lib /comptel/ilink/src/freeradius-server-2.1.12/src/lib/.libs/libfreeradius-radius.so -lnsl -lrt -lpthread -lc gcc: +b: No such file or directory gcc: /comptel/ilink/src/freeradius-server-2.1.12/src/lib/.libs:/comptel/ilink/xxxxxxxxxxxxxxxx32/lib: No such file or directory make[6]: *** [rlm_acctlog.la] Error 1
Probably, native ld is never invoked directly in FreeRADIUS build, so I've hacked ./configure script in this place:
if test "$with_gnu_ld" = no; then hardcode_libdir_flag_spec='${wl}+b ${wl}$libdir' hardcode_libdir_separator=:
case $host_cpu in hppa*64*|ia64*) hardcode_libdir_flag_spec_ld='+b $libdir' hardcode_direct=no hardcode_shlibpath_var=no ;; *) hardcode_direct=yes export_dynamic_flag_spec='${wl}-E'
# hardcode_minus_L: Not really in the search PATH, # but as the default location of the library. hardcode_minus_L=yes ;; esac fi
I replaced hardcode_libdir_flag_spec_ld='+b $libdir' with hardcode_libdir_flag_spec_ld='${wl}+b ${wl}$libdir' (quick and dirty fix), and this allowed me to continue: 2. raddb/Makefile uses one-argument form of 'ln -s', which is not present on HP-UX:
make[2]: Entering directory `/comptel/ilink/src/freeradius-server-2.1.12/raddb' Usage: ln [-f] [-i] [-s] f1 f2 ln [-f] [-i] [-s] f1 ... fn d1 make[2]: *** [all] Error 2 make[2]: Leaving directory `/comptel/ilink/src/freeradius-server-2.1.12/raddb'
I've fixed it this way: sed -i.orig 's/\(\<ln -s [^ ]*\);/\1 .;/' raddb/Makefile Regarding the 1st problem, I think the proper fix should instead ensure that hardcode_libdir_flag_spec is passed to gcc while hardcode_libdir_flag_spec_ld is passed to native ld only. These flags are not used in Makefiles, rules.mak or Make.inc, they are defined and used in ./configure - generated libtool script. I'll see if I can make a proper fix there. -- With best regards, xrgtn
Hello, On Fri, Jun 22, 2012 at 12:16:00PM +0300, Alexander Gattin wrote:
1. ld options '+b <libdir>' are passed without '-Wl,' prefix directly to gcc (not to ld):
gcc +b src/lib/.libs was in fact started by ./libtool:
/comptel/ilink/src/freeradius-server-2.1.12/libtool --mode=link gcc -release 2.1.12 \ -module -export-dynamic -o rlm_acctlog.la \ -rpath /comptel/ilink/xxxxxxxxxxxxxxxx32/lib rlm_acctlog.lo rlm_acctlog.c /comptel/ilink/src/freeradius-server-2.1.12/src/lib/libfreeradius-radius.la -lnsl -lrt -lpthread gcc -shared -Wl,+h -Wl,rlm_acctlog-2.1.12.so -Wl,+nodefaultrpath -o .libs/rlm_acctlog-2.1.12.so .libs/rlm_acctlog.o +b /comptel/ilink/src/freeradius-server-2.1.12/src/lib/.libs:/comptel/ilink/xxxxxxxxxxxxxxxx32/lib /comptel/ilink/src/freeradius-server-2.1.12/src/lib/.libs/libfreeradius-radius.so -lnsl -lrt -lpthread -lc gcc: +b: No such file or directory
I've made 2nd attempt at fixing the problem. I think that having distinct hardcode_libdir_flag_spec and hardcode_libdir_flag_spec_ld sets of flags is essential. You may want to link directly with native HP-UX /usr/bin/ld, and then you should use hardcode_libdir_flag_spec_ld, or you may want to use gcc and pass "+b" option and its value from gcc to linker using "-Wl," prefixes. With libtool you don't have and don't use distinct "c-link" and "native-link" modes, though. libtool is run with "--mode=link" and then it must decide which type of linker arguments to use by itself. My patch infers this (c-link vs native-link) by looking at 1st non-option argument to the libtool -- usually it's a command name, like "cc", "gcc" or "ld". The relevant part of libtool comes from ltmain.sh, so I'm ataching a patch for ltmain.sh (after applying the patch you'll need to re-run ./configure in order to produce new ./libtool). P.S. I'm actually fixing bug in ltmain.sh v1.5.22, and I suspect that the hardcode_libdir_flag_spec_ld problem is already fixed in newer versions of ltmain.sh. 1.5.22 is pretty old (2005/12/18). -- With best regards, xrgtn
Alexander Gattin wrote:
gcc +b src/lib/.libs was in fact started by ./libtool:
Yes. The version of libtool used by FreeRADIUS is quite old. Unfortunately, I've tried to upgrade it multiple times without much success. libtool, libltdl, and configure are incestuously related in bizarre ways. It's annoying, frustrating, and borderline incompetent.
P.S. I'm actually fixing bug in ltmain.sh v1.5.22, and I suspect that the hardcode_libdir_flag_spec_ld problem is already fixed in newer versions of ltmain.sh. 1.5.22 is pretty old (2005/12/18).
Exactly. I'm loath to upgrade libtool && libltdl. The code in the "master" branch (what will be 3.0) has a number of changes to the build system. It now can build without libtool or libltdl. The result is a build that is faster, simpler, and much better. Alan DeKok.
participants (2)
-
Alan DeKok -
Alexander Gattin