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