RE: AC_PROG

libtool-patches

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: AC_PROG_LD

From:	Boehne, Robert
Subject:	RE: AC_PROG_LD
Date:	Fri, 20 Dec 2002 18:10:41 -0500

John,

IMHO, this is definitely an issue with Cygnus configure, so
I would MUCH prefer if it was dealt with there. I concede
that in this particular case working around it in Libtool
isn't totally off the wall, but it breaks a fundamental
assumption that macro users should be able to make.
Albeit in a 99.99% harmless way. I just want you to know
I'm sympathetic to your trouble, and not just hiding behind
some lame excuse.

Thanks,

Robert

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

Robert,

I have submitted a gcc PR (9031) on the issue.

There is a problem with the macro:

# gcc -v -print-prog-name=ld
Reading specs from /opt/gnu64/lib/gcc-lib/hppa64-hp-hpux11.11/3.3/specs
/usr/ccs/bin/ld

Then, during configure
checking for ld used by GCC... ld

The ld used by gcc is /usr/ccs/bin/ld and it is never overridden by
what's in LD.

libtool uses gcc for linking and we need to ensure that appropriate
linker options are passed to the gcc linker. Thus, the libtool
configuration process needs to determine the linker used by gcc
and its type in order to correctly set options for it. It should
ignore what's in LD unless it sometimes uses it for linking as well.
Do you you see this as a viable approach?

I'm not arguing about your not wanting to clobber LD. If there
was a way to override the LD default in Cygnus configure, a user
would have to always define LD to the gcc linker if the linker
used by gcc wasn't ld. This isn't obvious, so I think it's the
wrong approach.

> 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
>
> ------_=_NextPart_001_01C2A866.6BCE06B0
> Content-Type: text/html
>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
> <HTML>
> <HEAD>
> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
> <META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
> <TITLE>RE: AC_PROG_LD</TITLE>
> </HEAD>
> <BODY>
>
> 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 [<A HREF="" href="mailto:address@hidden">mailto:address@hidden">mailto:address@hidden</A>]

> 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
> > > <A HREF="" href="http://mail.gnu.org/mailman/listinfo/libtool-patches" TARGET="_blank">http://mail.gnu.org/mailman/listinfo/libtool-patches" TARGET="_blank">http://mail.gnu.org/mailman/listinfo/libtool-patches</A>

> > 
> 
> 
>
> -- 
> J. David Anglin                                  address@hidden

> National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

> 
> 
>
> _______________________________________________
> Libtool-patches mailing list
> address@hidden
> <A HREF="" href="http://mail.gnu.org/mailman/listinfo/libtool-patches" TARGET="_blank">http://mail.gnu.org/mailman/listinfo/libtool-patches" TARGET="_blank">http://mail.gnu.org/mailman/listinfo/libtool-patches</A>

> 
>
> </BODY>
> </HTML>
> ------_=_NextPart_001_01C2A866.6BCE06B0--
>

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

[Prev in Thread]

Current Thread

[Next in Thread]

AC_PROG_LD, John David Anglin, 2002/12/17
- Re: AC_PROG_LD, Robert Boehne, 2002/12/20
 - Re: AC_PROG_LD, John David Anglin, 2002/12/20
- RE: AC_PROG_LD, Boehne, Robert, 2002/12/20
 - Re: AC_PROG_LD, Albert Chin, 2002/12/20
 - Re: AC_PROG_LD, John David Anglin, 2002/12/20
- RE: AC_PROG_LD, Boehne, Robert <=
 - Re: AC_PROG_LD, John David Anglin, 2002/12/20

Prev by Date: Re: AC_PROG_LD
Next by Date: Re: AC_PROG_LD
Previous by thread: Re: AC_PROG_LD
Next by thread: Re: AC_PROG_LD
Index(es):
- Date
- Thread