On Fri, 2007-06-22 at 17:25 -0700, Alan Coopersmith wrote:
> Laszlo (Laca) Peter wrote:
> > On Thu, 2007-06-21 at 13:53 -0700, Alan Coopersmith wrote:
> >> Can we state that libtool is highly not recommended and usually builds
> >> worse
> >> libraries than other systems?
> >
> > Hmm... define 'worse libraries'.
>
> It's insistence on overriding linker flags recommended by our linker
> experts has often annoyed me (so much that I use LD_OPTIONS to pass
> flags to ld behind libtool's back, so it can't overwrite them).
Oh yeah, that. (:
In JDS, we use a wrapper script around ld(1) and set LD to ld-wrapper
so that we can pass options to ld that libtool insists on dropping,
for example -z ignore. Perhaps we should publish a guide for working
around libtool's "issues".
> >> Has this version of libtool at least fixed the "impossible to build a
> >> 64-bit
> >> library correctly on Solaris" bugs? (Would have to dig into my old Xorg
> >> builds to see if I could find all the ways I had to work around libtool's
> >> damage, but as I recall it was forcing use of the -64 flag, assuming you
> >> linked shared libaries with ld, not cc.)
> >
> > Do you have more details of this bug?
>
> This code it inserts into configure scripts to force linking 64-bit
> libraries with the -64 flag, which in turn forces use of ld instead
> of cc/CC to link, since cc/CC don't support -64:
>
> sparc*-*solaris*)
> # Find out which ABI we are using.
> echo 'int i;' > conftest.$ac_ext
> if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5
> (eval $ac_compile) 2>&5
> ac_status=$?
> echo "$as_me:$LINENO: \$? = $ac_status" >&5
> (exit $ac_status); }; then
> case `/usr/bin/file conftest.o` in
> *64-bit*)
> case $lt_cv_prog_gnu_ld in
> yes*) LD="${LD-ld} -m elf64_sparc" ;;
> *) LD="${LD-ld} -64" ;;
> esac
> ;;
> esac
> fi
> rm -rf conftest*
> ;;
>
> It's in /opt/jdsbld/share/aclocal/libtool.m4 on a system with
> JDS CBE 1.5.1 installed - haven't checked in 1.6.
It's still there. I never noticed this because we use ld for
linking anyway.
Thanks,
Laca
