[Bug other/32078] Make FAILURE in 4.3.0 - `CXXFLAGS' has changed error causes "libltdl: No such file or directory"

["rob1weld at aol dot com" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #16 from rob1weld at aol dot com  2007-05-28 08:35 -------
>> Comment #11 From hjl@lucon.org 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