This is the mail archive of the
binutils@sourceware.cygnus.com
mailing list for the binutils project.
Re: [PATCH]: ld/Makefile.am
On Fri, Mar 10, 2000 at 03:15:59PM -0300, Alexandre Oliva wrote:
> On Mar 10, 2000, "H . J . Lu" <hjl@lucon.org> wrote:
>
> > OOops. Here is the complete log.
>
> Thanks
>
> > Maybe the wrong ld or gcc is used.
>
> I'd bet it's a wrong gcc. Could it be that, when you run `gcc', you
> somehow run a script of yours that runs the compiler under
> construction? You can check if that's the case by adding `-v' after
> `gcc ' in the definition of relink_command in the ld-new wrapper
> script.
I know what is going on. Please remember ld-new is called by collect2
from gcc. When collect2 calls ld-new, it sets up everything for the gcc
driver which calls it. In that case, it is the new gcc. The patch
below is the best I can think of.
H.J.
----
--- Makefile.in.orig Wed Mar 8 16:18:17 2000
+++ Makefile.in Fri Mar 10 10:43:32 2000
@@ -1457,6 +1457,17 @@ $(INSTALL_X11_MODULES): installdirs
# gcc is the only module which uses GCC_FLAGS_TO_PASS.
.PHONY: all-gcc
all-gcc:
+ # When configured with --enable-shared, libtool creates a
+ # script in the build directory which automatically relinks
+ # the program to search for shared libraries in the build
+ # directory. However, when ld/ld-new is called the first time
+ # from the new gcc, all the compiler environment variables are
+ # set to use the new gcc. ld/ld-new will use the new gcc to
+ # relink the new linker. It is incorrect. We cannot run
+ # ld/ld-new the first time from the new gcc. It is a very
+ # special case. We deal with it here.
+ -if test -f gcc/Makefile -a -x ld/ld-new -a -x ld/.libs/ld-new; then \
+ ld/ld-new -v >/dev/null 2>&1; fi
@if [ -f ./gcc/Makefile ] ; then \
r=`pwd`; export r; \
s=`cd $(srcdir); pwd`; export s; \