------- Comment #16 from rob1weld at aol dot com 2007-05-28 08:35 ------- >> Comment #11 From [EMAIL PROTECTED] 2007-05-27 07:24 >> Getting stuck at ?: >> libtool: compile: mv -f "process-Posix.o" "java/.libs/process-Posix.o" > ... >This isn't a fix.
Actually I tought if you had got that far that I had sent the "cheat" to work around the problem. I noticed that it was not included at the end of post eight. Sorry. I compose my messages in an editor and then paste them into the puny "Additional Comments:" box offline. I wish the box was wider and longer then I would compose online ... I looked at your attachment from post twelve. While I did not go that particular route it un-does someone else's work which could well be correct. I have you HUGE patch from http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01824.html and will review it. I also had a look at: http://gcc.gnu.org/viewcvs/trunk/libjava/configure?r1=125125&r2=125124&pathrev=125125 Thanks Paolo ... --- Here is what I found. I made a _one_ line patch that I am testing against 125123. The problem is that between revision 125031 and 125032 the ac_configure_args added (on _my_ system, might be different for you) this extra section: 'CXXFLAGS=-g -O2 -D_GNU_SOURCE' 'CXX= /opt/gcc-4_3-build/./gcc/xgcc -shared-libgcc -B/opt/gcc-4_3-build/./gcc -nostdinc++ -L/opt/gcc-4_3-build/i686-pc-linux-gnu/libstdc++-v3/src -L/opt/gcc-4_3-build/i686-pc-linux-gnu/libstdc++-v3/src/.libs -B/usr/i686-pc-linux-gnu/bin/ -B/usr/i686-pc-linux-gnu/lib/ -isystem /usr/i686-pc-linux-gnu/include -isystem /usr/i686-pc-linux-gnu/sys-include' 'LDFLAGS=' Go to libjava/configure and alter after the section with this text "# Remove --cache-file and --srcdir arguments so they do not pile up." to add a "echo "ac_sub_configure = $ac_sub_configure" command and it prints this: ac_sub_configure = '--cache-file=./config.cache' ... --cache-file= --srcdir= Later the un-modified section of the script prints: configure: configuring in classpath configure: running /bin/sh '/root/downloads/gcc-4_3-trunk/libjava/classpath/configure' --prefix=/usr '--cache-file=./config.cache' ... --cache-file=.././config.cache --srcdir=/root/downloads/gcc-4_3-trunk/libjava/classpath The second "--cache-file=.././config.cache" is a "neat idea" since it would make configuring quicker by using an already decided "config.cache" file. I _do_ like the idea but it would be better to use the "build-root"/"config.cache" instead of the "build-root"/libjava/"config.cache" file. Just two problems. First (it is said that) it wrecks using "Make -j", second, which is relevant to us, is that it uses a "config.cache" that was formed from section of the make that used `"CXXFLAGS_FOR_TARGET=-g -O2 -D_GNU_SOURCE"'. Why the two spaces? Anytime you see "junk" like ".//xyzdir" or, in this case " " it means that a variable was blank. (and the junk should be cleaned). Grep these examples: SYSROOT_CFLAGS_FOR_TARGET="--sysroot=$withval" CXXFLAGS_FOR_TARGET = $(CXXFLAGS) $(SYSROOT_CFLAGS_FOR_TARGET) LIBCXXFLAGS_FOR_TARGET = $(CXXFLAGS_FOR_TARGET) -fno-implicit-templates CFLAGS_FOR_TARGET = -O2 $(CFLAGS) $(SYSROOT_CFLAGS_FOR_TARGET) SYSROOT_CFLAGS_FOR_TARGET = @SYSROOT_CFLAGS_FOR_TARGET@ CXXFLAGS_FOR_TARGET = $(CXXFLAGS) $(SYSROOT_CFLAGS_FOR_TARGET) CXXFLAGS=$$(CXXFLAGS_FOR_TARGET) See? CXXFLAGS = CXXFLAGS_FOR_TARGET = "CXXFLAGS SYSROOT_CFLAGS_FOR_TARGET" If "SYSROOT_CFLAGS_FOR_TARGET" is blank you end up with this happening: `"CXXFLAGS_FOR_TARGET=-g -O2 -D_GNU_SOURCE"' Other trouble is some un-substituted "AT"'s ... # grep -B 9 -A 18 --color=always GNU_SOURCE /root/downloads/gcc-4_3-trunk/libjava/Makefile.in AM_CXXFLAGS = \ -fno-rtti \ -fnon-call-exceptions \ $(THREADCXXFLAGS) \ -fdollars-in-identifiers \ -Wswitch-enum \ -D_FILE_OFFSET_BITS=64 \ @LIBGCJ_CXXFLAGS@ \ $(WARNINGS) \ -D_GNU_SOURCE \ -DPREFIX="\"$(prefix)\"" \ -DTOOLEXECLIBDIR="\"$(toolexeclibdir)\"" \ -DJAVA_HOME="\"$(JAVA_HOME_DIR)\"" \ -DBOOT_CLASS_PATH="\"$(BOOT_CLASS_PATH_DIR)\"" \ -DJAVA_EXT_DIRS="\"$(jardir)/ext\"" \ -DGCJ_ENDORSED_DIRS="\"$(jardir)/gcj-endorsed\"" \ -DGCJ_VERSIONED_LIBDIR="\"$(dbexecdir)\"" \ -DPATH_SEPARATOR="\"$(CLASSPATH_SEPARATOR)\"" \ -DECJ_JAR_FILE="\"$(ECJ_JAR)\"" \ -DLIBGCJ_DEFAULT_DATABASE="\"$(dbexecdir)/$(db_name)\"" \ -DLIBGCJ_DEFAULT_DATABASE_PATH_TAIL="\"$(db_pathtail)\"" AM_GCJFLAGS = \ @LIBGCJ_JAVAFLAGS@ \ -fclasspath= -fbootclasspath=$(BOOTCLASSPATH) \ --encoding=UTF-8 \ Combine all those problems and try to share cache files while calling individual configure scripts with arguments that conflict with the cache and what happens - this bug and more to come. To fix _this_ bug and IGNORE the perils that await use this diff on revision 125123: --- libjava/configure 2007-05-28 01:00:43.000000000 -0700 +++ libjava/configure-hack 2007-05-28 01:03:36.000000000 -0700 @@ -31160,10 +31160,6 @@ ac_sub_cache_file=$ac_top_builddir$cache_file ;; esac +# Disgusting (simplest) hack to fix very broken code needing a lot of work. +# See: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32078 +ac_sub_cache_file=./config.cache + { echo "$as_me:$LINENO: running $ac_sub_configure $ac_sub_configure_args --cache-file=$ac_sub_cache_file --srcdir=$ac_srcdir" >&5 echo "$as_me: running $ac_sub_configure $ac_sub_configure_args --cache-file=$ac_sub_cache_file --srcdir=$ac_srcdir" >&6;} # The eval makes quoting arguments work. That simply sets the "CONFIG_SUBDIRS" section to use it's _own_ cache instead of one from another directory. That is the only work it un-does. It leaves all the other work (good or bad) intact and lets libjava compile while we take a good look at what to fix. Which it would seem you two have done. I opted to try a one-liner. I will study your work and update my copy. It's been a long day for us all. Thank you for your efforts. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32078
