Final end of the `never ending story'? (was: Re: Patch for configuring/building in ${srcdir} (was: Re: Does it work now with my patch? (was: Re: egcs-980221: build fails for shared libstdc++ on HP-UX 10.20)) )

Manfred Hollstein manfred@s-direktnet.de
Tue Mar 3 10:50:00 GMT 1998


On Tue, 3 March 1998, 10:09:25, law@hurl.cygnus.com wrote:

 > 
 >   In message < 9803031322.AA14928@lts.sel.alcatel.de >you write:
 > 
 >   >  > Wasn't this what your original fixes were supposed to correct? :-(
 >   > 
 >   > Note, this is a different failure than before. At least the PICFLAGS are
 >   > now in the commandline ;-)
 >   > 
 >   > But, what the h... am I doing different? I tested this today on SunOS 4,
 >   > too, hence I don't know why it's still failing for you.
 > If you're using GNU ld, then you won't get this error.
 > 
 > For reasons unknown the stunos linker won't let you mix -fpic and -fPIC.
 > 
 > jeff

You're right, but my initial PICFLAGS patch was supposed to fix that (because
at that time I had to use SunOS ld).

In the meantime, I got a little bit further. It looks like, some of the libiberty
.o files get re-used even for different parts of the multilib :-? This does occur
even with GNU make; I just hacked config/t-linux to use a similar multilib
configuration as SunOS's and build a tree.

Oops, build is nearly finished. Now I know, why it's failing:

the link tree mechanism fails: look at where the links point to:

$ ll libraries/libiberty
total 510
drwxr-xr-x   4 manfred  users        3072 Mar  3 18:03 .
drwxr-xr-x   8 manfred  users        1024 Mar  3 18:17 ..
lrwxrwxrwx   1 manfred  users          29 Mar  3 18:02 COPYING.LIB -> ../.././libiberty/COPYING.LIB
lrwxrwxrwx   1 manfred  users          27 Mar  3 18:02 ChangeLog -> ../.././libiberty/ChangeLog
-rw-r--r--   1 manfred  users       13300 Mar  3 18:03 Makefile
lrwxrwxrwx   1 manfred  users          29 Mar  3 18:02 Makefile.in -> ../.././libiberty/Makefile.in
lrwxrwxrwx   1 manfred  users          24 Mar  3 18:02 README -> ../.././libiberty/README
lrwxrwxrwx   1 manfred  users          32 Mar  3 18:02 alloca-botch.h -> ../.././libiberty/alloca-botch.h
lrwxrwxrwx   1 manfred  users          15 Mar  3 18:03 alloca-conf.h -> ./alloca-norm.h
lrwxrwxrwx   1 manfred  users          31 Mar  3 18:02 alloca-norm.h -> ../.././libiberty/alloca-norm.h
lrwxrwxrwx   1 manfred  users          26 Mar  3 18:02 alloca.c -> ../.././libiberty/alloca.c
lrwxrwxrwx   1 manfred  users          24 Mar  3 18:02 argv.c -> ../.././libiberty/argv.c
-rw-r--r--   1 manfred  users        5532 Mar  3 18:03 argv.o

and so on; this one is OK, but:

$ ll libraries/pentium/libiberty:
total 23
drwxr-xr-x   4 manfred  users        3072 Mar  3 18:04 .
drwxr-xr-x   5 manfred  users        1024 Mar  3 18:18 ..
lrwxrwxrwx   1 manfred  users          30 Mar  3 18:03 COPYING.LIB -> ../../../libiberty/COPYING.LIB
lrwxrwxrwx   1 manfred  users          28 Mar  3 18:03 ChangeLog -> ../../../libiberty/ChangeLog
-rw-r--r--   1 manfred  users       11785 Mar  3 18:03 Makefile
lrwxrwxrwx   1 manfred  users          30 Mar  3 18:03 Makefile.in -> ../../../libiberty/Makefile.in
lrwxrwxrwx   1 manfred  users          25 Mar  3 18:03 README -> ../../../libiberty/README
lrwxrwxrwx   1 manfred  users          33 Mar  3 18:03 alloca-botch.h -> ../../../libiberty/alloca-botch.h
lrwxrwxrwx   1 manfred  users          15 Mar  3 18:03 alloca-conf.h -> ./alloca-norm.h
lrwxrwxrwx   1 manfred  users          32 Mar  3 18:03 alloca-norm.h -> ../../../libiberty/alloca-norm.h
lrwxrwxrwx   1 manfred  users          27 Mar  3 18:03 alloca.c -> ../../../libiberty/alloca.c
lrwxrwxrwx   1 manfred  users          25 Mar  3 18:03 argv.c -> ../../../libiberty/argv.c
lrwxrwxrwx   1 manfred  users          25 Mar  3 18:03 argv.o -> ../../../libiberty/argv.o

Look at argv.o, it's a symbolic link !-(

Interestingly, it only fails in the libiberty dirs, while libio and
libstdc++ are OK!

What an odd problem - who needs any more arguments to _strongly_ advise
srcdir != objdir!!!!!!!!!!????????!!!!!!!!

OK, some echo's here and there (and everywhere... - nice song, Paul), now
I believe I have the final fix - this one should be applied _in addition_ to
the last one:

Tue Mar  3 19:42:04 1998  Manfred Hollstein  <manfred@s-direktnet.de>

	* Makefile.in ($(CONFIGURE_TARGET_MODULES)): Call make clean after
	configure to make sure no .o files got simply linked from higher level
	directories.

diff -up egcs-980301.orig/Makefile.in egcs-980301/Makefile.in
--- egcs-980301.orig/Makefile.in	Thu Feb 19 18:26:00 1998
+++ egcs-980301/Makefile.in	Tue Mar  3 19:46:30 1998
@@ -1174,6 +1174,15 @@ $(CONFIGURE_TARGET_MODULES):
 	      CONFIG_SITE=/dev/null $(SHELL) $$s/configure \
 		$(CONFIG_ARGUMENTS) $${srcdiroption} \
 		--with-target-subdir="$(TARGET_SUBDIR)"; \
+	    fi; \
+	    if [ "$(srcdir)" = "." -a "$(TARGET_SUBDIR)" != "." -a -f Makefile ]; then \
+	      if $(MAKE) clean; then \
+	        true; \
+	      else \
+	        exit 1; \
+	      fi; \
+	    else \
+	      true; \
 	    fi; \
 	  else \
 	    true; \



More information about the Gcc-bugs mailing list