RE: AC_PROG_LD

[Boehne, Robert]

John,

So long as Cygnus configure doesn't clobber your LD setting
you should be able to run AC_PROG_LD before.  I refuse to
clobber LD, this isn't supposed to happen so a better approach
would be to fix Cygnus configure so that it won't clobber LD
rather than teaching Libtool to re-clobber it.  It isn't often
I have a strong opinion about a patch, but this qualifies.

HTH,

Robert

-----Original Message-----
From: John David Anglin [mailto:address@hidden]
Sent: Friday, December 20, 2002 1:33 PM
To: address@hidden
Cc: address@hidden
Subject: Re: AC_PROG_LD

Robert,

I am not setting LD explicitly.  LD is set by Cygnus configure.
Currently, Cygnus configure doesn't allow you to override the
default that it sets for LD.  If the ld used by gcc is not ld,
AC_PROG_LD doesn't set LD, and libtool uses the wrong linker.
Cygnus configure has no way of knowing that libtool needs the
ld used by gcc.

> John,
>
> After careful consideration, I've decided to reject this patch.
> To control "configure" users can set many variables, CC, CXX, SED
> and LD.  Any checks that might set these variables has to test
> to see if the user, or perhaps a top-level configure.ac macro,
> has explicitly set it.  Breaking this for any of these shell variables
> would change expected behavior.  As I see the problem you're running
> into,
> it is caused by incorrectly setting $LD explicitly.  I would suggest

>
> HTH,
>
> Robert
>
> John David Anglin wrote:
> >
> > The toplevel configure scripts in binutils and gcc define LD=ld in native
> > (non-canadian cross) builds.  This causes the AC_PROG_LD to select the
> > default value of ld.  As result, packages are misconfigured if the linker
> > used by GCC is not ld.  In the case of binutils, this causes a build
> > error linking libbfd due to incorrect linker options being selected by
> > libtool.
> >
> > The enclosed patch changes the behavior of AC_PROG_LD to choose the GCC
> > linker when it encounters the default value of "ld".  The other possible
> > fix is to not define LD in the toplevel configure script.  However, as
> > this is used for many different packages, I think there are circumstances
> > when libtool is not being used that require a default value for LD.
> >
> > Dave
> > --
> > J. David Anglin                                  address@hidden
> > National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)
> >
> > 2002-12-17  John David Anglin  <address@hidden>
> >
> >         * libtool.m4 (AC_PROG_LD): Use ld used by GCC when LD is set to "ld".
> >
> > Index: libtool.m4
> > ===================================================================
> > RCS file: /home/cvs/libtool/libtool.m4,v
> > retrieving revision 1.280
> > diff -u -3 -p -r1.280 libtool.m4
> > --- libtool.m4  11 Dec 2002 19:44:59 -0000      1.280
> > +++ libtool.m4  17 Dec 2002 18:56:42 -0000
> > @@ -1875,7 +1875,9 @@ if test "$GCC" = yes; then
> >        while echo $ac_prog | grep "$re_direlt" > /dev/null 2>&1; do
> >         ac_prog=`echo $ac_prog| sed "s%$re_direlt%/%"`
> >        done
> > -      test -z "$LD" && LD="$ac_prog"
> > +      if test -z "$LD" || test "$LD" = ld; then
> > +       LD="$ac_prog"
> > +      fi
> >        ;;
> >    "")
> >      # If it fails, then pretend we aren't using GCC.
> >
> > _______________________________________________
> > Libtool-patches mailing list
> > address@hidden
> > http://mail.gnu.org/mailman/listinfo/libtool-patches
>

--
J. David Anglin                                  address@hidden
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

_______________________________________________
Libtool-patches mailing list
address@hidden
http://mail.gnu.org/mailman/listinfo/libtool-patches