Found an additional problem.

After all the stages are done and we are building the libraries in the "target name directory" (EG: in _my_ case the directory is called "i686-pc-linux-gnu") we must _always_ use "xgcc" and NOT "gcc" (the OS's compiler).

Correct?


Here is a bit of screen output:


make[2]: Leaving directory `/opt/gcc-4_3-build/i686-pc-linux-gnu/boehm-gc'
make[2]: Entering directory `/opt/gcc-4_3-build/i686-pc-linux-gnu/libobjc'
: make ; exec true "AR=ar" "AR_FLAGS=rc" "CC=/opt/gcc-4_3-build/./gcc/xgcc -B/opt/gcc-4_3-build/./gcc/ -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" "CFLAGS=-O2 -g -O2 " "DESTDIR=" "LIBCFLAGS=-O2 -g -O2 " "EXTRA_OFILES=" 


That is OK.


Here is some more (from the build log):

# grep -A 4 /opt/gcc-4_3-build/i686-pc-linux-gnu/libjava/classpath/native/fdlibm gcc-4_3-build/make_6*

gcc-4_3-build/make_6b_log.txt:make[5]: Entering directory `/opt/gcc-4_3-build/i686-pc-linux-gnu/libjava/classpath/native/fdlibm'
gcc-4_3-build/make_6b_log.txt-if /bin/sh ../../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I/root/downloads/gcc-4_3-trunk/libjava/classpath/native/fdlibm -I../../include     -O2 -g -O2  -MT dtoa.lo -MD -MP -MF ".deps/dtoa.Tpo" -c -o dtoa.lo /root/downloads/gcc-4_3-trunk/libjava/classpath/native/fdlibm/dtoa.c; \
gcc-4_3-build/make_6b_log.txt-  then mv -f ".deps/dtoa.Tpo" ".deps/dtoa.Plo"; else rm -f ".deps/dtoa.Tpo"; exit 1; fi
gcc-4_3-build/make_6b_log.txt-mkdir .libs
gcc-4_3-build/make_6b_log.txt-gcc -DHAVE_CONFIG_H -I. -I/root/downloads/gcc-4_3-trunk/libjava/classpath/native/fdlibm -I../../include -O2 -g -O2 -MT dtoa.lo -MD -MP -MF .deps/dtoa.Tpo -c /root/downloads/gcc-4_3-trunk/libjava/classpath/native/fdlibm/dtoa.c  -fPIC -DPIC -o .libs/dtoa.o



Notice that is uses "gcc" to build dtoa ...

When I compiled gcc previously it didn't do that:


# grep -A 4 /opt/gcc-4_3-build/i686-pc-linux-gnu/libjava/classpath/native/fdlibm make_5*

make_5c_log.txt:make[5]: Entering directory `/opt/gcc-4_3-build/i686-pc-linux-gnu/libjava/classpath/native/fdlibm'
make_5c_log.txt-if /bin/sh ../../libtool --mode=compile /opt/gcc-4_3-build/./gcc/xgcc -B/opt/gcc-4_3-build/./gcc/ -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 -DHAVE_CONFIG_H -I. -I/root/downloads/gcc-4_3-trunk/libjava/classpath/native/fdlibm -I../../include     -O2 -g -O2  -MT dtoa.lo -MD -MP -MF ".deps/dtoa.Tpo" -c -o dtoa.lo /root/downloads/gcc-4_3-trunk/libjava/classpath/native/fdlibm/dtoa.c; \
make_5c_log.txt-        then mv -f ".deps/dtoa.Tpo" ".deps/dtoa.Plo"; else rm -f ".deps/dtoa.Tpo"; exit 1; fi
make_5c_log.txt-mkdir .libs
make_5c_log.txt-/opt/gcc-4_3-build/./gcc/xgcc -B/opt/gcc-4_3-build/./gcc/ -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 -DHAVE_CONFIG_H -I. -I/root/downloads/gcc-4_3-trunk/libjava/classpath/native/fdlibm -I../../include -O2 -g -O2 -MT dtoa.lo -MD -MP -MF .deps/dtoa.Tpo -c /root/downloads/gcc-4_3-trunk/libjava/classpath/native/fdlibm/dtoa.c  -fPIC -DPIC -o .libs/dtoa.o


That is not the only library where this occurs. The tests will be invalid if gcc is used instead of xgcc. The gcc-bugs scripts will be sending out false e-mails about breakages.

I saw it with revision 125032 on a quad-core Linux/x86-64 with "make -j4".

 Do either of you read the list?
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01665.html

>> Andrew Pinski 2007-05-25 15:17 
>> Do either of you read the list?

I search the Internet and use the search page at http://gcc.gnu.org/bugzilla before I post a bug. I try to avoid dupes and look for fixes.

There may well be some wait time before http://gcc.gnu.org/ml/gcc-patches shows up on Google. Is there a wait time before http://gcc.gnu.org/ml/gcc-patches shows up on http://gcc.gnu.org/bugzilla ?


Bug two is not addressed in the thread you mentioned (and has been present for months) - I do avoid complaining when I can.

Thanks for working on bug one.

This looks like it might be the same as this one http://sourceware.org/ml/newlib/2007/msg00425.html

Anyone able to try that patch?

After winding up and down, back and forth through what seems to be a couple of forks of discussion, I found a couple of different answers ...

The above comment means that the "References:" section at the bottom of the posts changes on some posts and leads to other posts with different lists of references - instead of simply being able to click-next.


The gist of it seems to be that the SVN was updated for all to obtain without first testing amounst the maintainers (or other designated group):
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01654.html


One person says it is fixed already:
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01672.html

In another post they might have it fixed on the WEEKEND:
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01692.html

From http://gcc.gnu.org/viewcvs?view=rev&revision=125032, it appears that
libjava/libltdl was omitted from the regeneration as well.

>> Do either of you read the list?
Good point, here are some others ...


1): The newly updated libltdl directory that has caused some breakage in
    the libjava directory is version 1.5.16 - see:

# grep -A1 VERSION gcc-4_3-trunk/libjava/libltdl/ltmain.sh | head -n 2
VERSION=1.5.16
TIMESTAMP=" (1.1220.2.235 2005/04/25 18:13:26)"


2): Version 1.5.22 is 9 months newer than version 1.5.16 . The version numbers
    for libtool are even only; we could use a version that was 4 revisions newer.


Here is an URL no one thought to check - funny?
http://ftp.gnu.org/gnu/libtool/
libtool-1.5.12.tar.gz              05-Feb-2005 11:38   2.6M
libtool-1.5.14.tar.gz              12-Feb-2005 08:43   2.6M 
libtool-1.5.16.tar.gz              25-Apr-2005 14:35   2.6M 
libtool-1.5.18.tar.gz              16-May-2005 06:19   2.7M 
libtool-1.5.20.tar.gz              31-Aug-2005 15:07   2.7M 
libtool-1.5.22.tar.gz              18-Dec-2005 17:26   2.8M  


3): The "libtool-1.5.22.tar.gz" "NEWS" file mentions many bugfixes.
    The "Changelog" file lists over 750 lines of info since 1.5.16 .


4): You can do this (adjust these instructions for your directory structure 
    and available software configuration) if your target is i686-pc-linux-gnu

# cd /downloads
# wget http://ftp.gnu.org/gnu/libtool/libtool-1.5.22.tar.gz
# gunzip -d libtool-1.5.22.tar.gz
# tar -xf libtool-1.5.22.tar
# mv gcc-4_3-trunk/libjava/libltdl gcc-4_3-trunk/libjava/libltdl-Origonal
# mkdir gcc-4_3-trunk/libjava/libltdl
# cp /downloads/libtool-1.5.22/libltdl/* gcc-4_3-trunk/libjava/libltdl
# cd /opt/gcc-4_3-build
# /downloadsgcc-4_3-trunk/configure
# make


Do NOT alter /downloads/gcc-4_3-trunk/libjava/libtool-version unless you 
read the docs and know what you are doing. Do NOT change it to 1.5.22 !

Just copy the ONE directory, do not copy any other or do any configuring.

Remember to rename the directory structure back the way it was _prior_
to running "contrib/gcc_update" or "svn" until this fix is approved.


After copying that one directory you can type this:

# grep -A1 VERSION /downloads/gcc-4_3-trunk/libjava/libltdl/ltmain.sh | head -n 2
VERSION=1.5.22
TIMESTAMP=" (1.1220.2.365 2005/12/18 22:14:06)"


Now things are fixed with respect to libltdl - no need for patching (on _my_ platform, other people must test before committing to SVN or we will be back in the same boat).



While people are fixing the problem in this area ...

Here are some of the problems with file: /root/downloads/gcc-4_3-trunk/libjava/configure
see here at line 8093, how CXXCPP is being set - seems wrong for libjava.

echo $ECHO_N "checking how to run the C++ preprocessor... $ECHO_C" >&6
if test -z "$CXXCPP"; then
  if test "${ac_cv_prog_CXXCPP+set}" = set; then
  echo $ECHO_N "(cached) $ECHO_C" >&6
else
      # Double quotes because CXXCPP needs to be expanded
    for CXXCPP in "$CXX -E" "/lib/cpp"
    do



Your system might be different but here is what mine says about CXX and /lib/cpp .


# echo $CXX 
(BLANK LINE)
# 


# ls -l /lib/cpp
lrwxrwxrwx 1 root root 21 Apr 21 14:40 /lib/cpp -> /etc/alternatives/cpp
# ls -l /etc/alternatives/cpp
lrwxrwxrwx 1 root root 12 Apr 21 14:40 /etc/alternatives/cpp -> /usr/bin/cpp
# ls -l /usr/bin/cpp
-rwxr-xr-x 1 root root 512405 May  4 10:33 /usr/bin/cpp
# /usr/bin/cpp --version
cpp (GCC) 4.2.0 20070501 (prerelease)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
(BLANK LINE)
# 


# gcc-4_3-build/gcc/cpp --version
cpp (GCC) 4.3.0 20070526 (experimental)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
(BLANK LINE)
# 


Which "cpp" version are we _supposed_ to use ? Why look at /lib/cpp to get a link to a link, why not just look at "/usr/bin/cpp"; or are you trying to find a hook for an alternate compiler that might be available.

Wouldn't you rather use the 4.3.0 revision of "cpp" that you just built ?

If you use "/usr/bin/cpp" you must get your "-B"'s right and not use any 4.3.0
commands. Your "/usr/bin/cpp" might be version 3.4 or lower.



Anyways ...

After copying in the newest libltdl everything seems to configure and compile
file with respect to libltdl issues only - other problems are in other bug reports.

Getting stuck at ?:

libtool: compile: mv -f "process-Posix.o" "java/.libs/process-Posix.o"
mv: cannot stat `process-Posix.o': No such file or directory
_OR_
libtool: compile: mv -f "awt.o" "gnu/.libs/awt.o"
mv: cannot stat `awt.o': No such file or directory
make[3]: *** [java/process-Posix.lo] Error 1
make[3]: Leaving directory `/opt/gcc-4_3-build/i686-pc-linux-gnu/libjava'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/opt/gcc-4_3-build/i686-pc-linux-gnu/libjava'
make[1]: *** [all-target-libjava] Error 2
make[1]: Leaving directory `/opt/gcc-4_3-build'


(Again, adjust these instructions to your situation, see above)

# cd /downloads/libtool-1.5.22/
# ./configure
# cp /downloads/libtool-1.5.22/libtool /opt/gcc-4_3-build/i686-pc-linux-gnu/libjava
# cd /opt/gcc-4_3-build
# make


Everything _seems_ fixed on i686-pc-linux-gnu (Debian GNU/Linux)

It worked.

To _properly_ integrate the new Libtool to the SVN (for ONLY _this_ bug fix) requires reading the DOCs (EG: File: libtool.info,  Node: AC_PROG_LIBTOOL and Node: Distributing and Node: Libltdl interface) you may also need to do a regenerate to avoid the requirement that people have autoconf and automake etc. 

The `libtoolize' program provides a standard way to add libtool support to your package. Use the "-n" option since you don't want to overwrite some newer files. The "Libtool test suite" (make check in libtool-1.5.22) passed on my system.

It would seem that all that needs to be done to fix ONLY _this_ bug is the above mentioned directory copy procedure. Leave the libtool.m4 file since it might be needed by some other older software. New libtool won't use it.

I ONLY fixed the _one_ problem mentioned in this bug report. I did not upgrade my OS's libtool by "make install"ing libtool-1.5.22 or make any excess changes. I got a 100% "make check" pass - see below.


You might want to do this (I didn't):
cp /root/downloads/libtool-1.5.22/ltmain.sh /root/downloads/gcc-4_3-trunk/ltmain.sh


Now that I've tested my small fix I'll let the dust settle and see what the maintainers decide to do - just fix this one spot or upgrade ALL of gcc to use the newer libtool.


To _properly_ upgrade ALL of gcc to use this newer libtool we would need to fix a few more directories. I do not know if that will creates new bugs.

There are "libtool-version" files in directories: gcc-4_3-trunk/libgfortran ,
gcc-4_3-trunk/libmudflap , gcc-4_3-trunk/libffi , gcc-4_3-trunk/libssp ,
and gcc-4_3-trunk/libjava .

There are "ltmain.sh" files in directories: gcc-4_3-trunk/ (SVN root),
gcc-4_3-trunk/libjava/libltdl , and gcc-4_3-trunk/libjava/classpath .

You need to add "AC_PROG_LIBTOOL" to each affected directories "configure.ac".


Now regenerate and it should work for everyone. It _did_ work for _me_ when I copied _only_ the gcc-4_3-trunk/libjava/libltdl directory (without pre-configuring it, I let gcc's configure do it) and I copied the pre-configured libtool file over to the libjava directory. Not the "approved" method, just one that avoids making too many changes.


_IF_ this works for many people during the next week and someone integrates 
this with the SVN, (and everyone is happy), then this bug is closed.



# gcc/xgcc -v 2>&1 | tail -n 1
gcc version 4.3.0 20070526 (experimental)
# cat LAST_UPDATED 
Sat May 26 05:23:11 UTC 2007 (revision 125087)


Here is my "make -i check" for libjava:

Test Run By root on Sat May 26 22:25:40 2007
                === libjava Summary ===
# of expected passes            2538


That is ALL it printed. No:
"unexpected failures", "unexpected successes", "expected failures",
"unresolved testcases", "untested testcases", or "unsupported tests" !

Libjava Passed 100% OK.


Test results are here:
http://gcc.gnu.org/ml/gcc-testresults/2007-05/msg01322.html

(In reply to comment #9)
> Getting stuck at ?:
> 
> libtool: compile: mv -f "process-Posix.o" "java/.libs/process-Posix.o"
> mv: cannot stat `process-Posix.o': No such file or directory
> _OR_
> libtool: compile: mv -f "awt.o" "gnu/.libs/awt.o"
> mv: cannot stat `awt.o': No such file or directory
> make[3]: *** [java/process-Posix.lo] Error 1
> make[3]: Leaving directory `/opt/gcc-4_3-build/i686-pc-linux-gnu/libjava'
> make[2]: *** [all-recursive] Error 1
> make[2]: Leaving directory `/opt/gcc-4_3-build/i686-pc-linux-gnu/libjava'
> make[1]: *** [all-target-libjava] Error 2
> make[1]: Leaving directory `/opt/gcc-4_3-build'

See

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32098

> 
> 
> (Again, adjust these instructions to your situation, see above)
> 
> # cd /downloads/libtool-1.5.22/
> # ./configure
> # cp /downloads/libtool-1.5.22/libtool
> /opt/gcc-4_3-build/i686-pc-linux-gnu/libjava
> # cd /opt/gcc-4_3-build
> # make
>

This isn't a fix.

Created attachment 13617 [details]
A kludge to work around the autoconf bug.

This is a kludge which allows me to go further in libjava build.

A patch to update libtool in classpath is posted at

http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01824.html

Test results on Linux/x86-64 looks good:

http://gcc.gnu.org/ml/gcc-testresults/2007-05/msg01337.html

This patch allows libjava to build:

http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01843.html

Subject: Bug 32078

Author: bonzini
Date: Mon May 28 06:38:00 2007
New Revision: 125125

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125125
Log:
2007-05-27  Paolo Bonzini  <bonzini@gnu.org>

	PR bootstrap/32078
	* configure.ac: Include confsubdir.m4.
	* configure: Regenerate.

Modified:
    trunk/libjava/ChangeLog
    trunk/libjava/configure
    trunk/libjava/configure.ac

>> 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.

# cat /root/downloads/gcc-4_3-trunk/LAST_UPDATED                         
Mon May 28 08:39:31 UTC 2007 (revision 125125M)

Results for 4.3.0 20070528 (experimental) testsuite on i686-pc-linux-gnu
http://gcc.gnu.org/ml/gcc-testresults/2007-05/msg01375.html

Again, Java passed 100%, and I enabled a lot of options.

I un-did all _my_ work and re-got the SVN to check that it builds - it doesn't.


Here is proof and result:

# cd /root/downloads/gcc-4_3-trunk

# cat LAST_UPDATED 
Tue May 29 15:18:17 UTC 2007 (revision 125164)

# svn di -r 125164
(Prints NOTHING)

# gcc/xgcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /root/downloads/gcc-4_3-trunk/configure --verbose --enable-languages=c,ada,c++,fortran,java,objc,obj-c++ --with-tune=athlon-xp --prefix=/usr --enable-objc-gc --enable-concept-checks --disable-multilib --with-gxx-include-dir=/usr/include/c++/4.3 --enable-libstdcxx-debug --enable-static --enable-shared --enable-initfini-array --enable-__cxa_atexit --enable-threads=posix --enable-version-specific-runtime-libs --enable-libssp --enable-libmudflap --enable-libgomp --disable-werror --enable-nls --with-included-gettext --enable-decimal-float --with-long-double-128 --enable-debug --enable-java-gc=boehm --with-x --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --enable-java-awt=gtk,xlib --enable-gtk-cairo --enable-qt-peer --enable-xmlj --enable-gconf-peer --enable-tool-wrappers --enable-portable-native-sync --enable-examples --enable-libgcj-multifile --with-stabs --enable-hash-synchronization --enable-gc-debug --enable-interpreter --with-system-zlib --enable-libada --with-tls --with-cpu=athlon-xp --with-arch=athlon-xp --enable-haifa --enable-stage1-checking=assert,gc,misc,rtl,rtlflag,runtime,tree
Thread model: posix
gcc version 4.3.0 20070529 (experimental)


# cd /opt/gcc-4_3-build
# make
...(Many Many lines)
make[3]: Entering directory `/opt/gcc-4_3-build/i686-pc-linux-gnu/libjava'
make create-headers
make[4]: Entering directory `/opt/gcc-4_3-build/i686-pc-linux-gnu/libjava'
echo > gcjh.stamp
make[4]: Leaving directory `/opt/gcc-4_3-build/i686-pc-linux-gnu/libjava'
depbase=`echo jni-libjvm.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`; \
        if /bin/sh ./libtool --tag=CXX --mode=compile /opt/gcc-4_3-build/./gcc/xgcc .... -o jni-libjvm.lo /root/downloads/gcc-4_3-trunk/libjava/jni-libjvm.cc; \
        then mv -f "$depbase.Tpo" "$depbase.Plo"; else rm -f "$depbase.Tpo"; exit 1; fi
libtool: compile:  /opt/gcc-4_3-build/./gcc/xgcc .... -c /root/downloads/gcc-4_3-trunk/libjava/jni-libjvm.cc  -fPIC -DPIC -o .libs/jni-libjvm.o
libtool: compile:  /opt/gcc-4_3-build/./gcc/xgcc .... -c /root/downloads/gcc-4_3-trunk/libjava/jni-libjvm.cc -o jni-libjvm.o >/dev/null 2>&1
...(Many lines)
        if /bin/sh ./libtool --tag=CXX --mode=compile /opt/gcc-4_3-build/./gcc/xgcc .... -o posix-threads.lo /root/downloads/gcc-4_3-trunk/libjava/posix-threads.cc; \
        then mv -f "$depbase.Tpo" "$depbase.Plo"; else rm -f "$depbase.Tpo"; exit 1; fi
libtool: compile:  /opt/gcc-4_3-build/./gcc/xgcc .... -c /root/downloads/gcc-4_3-trunk/libjava/posix-threads.cc  -fPIC -DPIC -o .libs/posix-threads.o
libtool: compile:  /opt/gcc-4_3-build/./gcc/xgcc .... -c /root/downloads/gcc-4_3-trunk/libjava/posix-threads.cc -o posix-threads.o >/dev/null 2>&1
here=`pwd`; cd /root/downloads/gcc-4_3-trunk/libjava/classpath/lib; \
        find gnu java javax org sun -name .svn -prune -o -name '*.class' -print | \
        jar -cfM@ $here/libgcj-4.3.0.jar


Note the above section uses "./libtool --tag=CXX --mode=compile" and works fine.
Note the next  section uses "./libtool --tag=GCJ --mode=compile" and fails after a few files.


/bin/sh ./libtool --tag=GCJ --mode=compile .... /root/downloads/gcc-4_3-trunk/libjava/classpath/lib/java/lang/Object.class
libtool: compile:  /opt/gcc-4_3-build/gcc/gcj .... /root/downloads/gcc-4_3-trunk/libjava/classpath/lib/java/lang/Object.class 
libtool: compile: mv -f "Object.o" "java/lang/.libs/Object.o"
libtool: compile:  /opt/gcc-4_3-build/gcc/gcj .... /root/downloads/gcc-4_3-trunk/libjava/classpath/lib/java/lang/Object.class >/dev/null 2>&1
libtool: compile: mv -f "Object.o" "java/lang/Object.o"
/bin/sh ./libtool --tag=GCJ --mode=compile .... /root/downloads/gcc-4_3-trunk/libjava/classpath/lib/java/lang/Class.class
libtool: compile:  /opt/gcc-4_3-build/gcc/gcj .... /root/downloads/gcc-4_3-trunk/libjava/classpath/lib/java/lang/Class.class 
libtool: compile: mv -f "Class.o" "java/lang/.libs/Class.o"
libtool: compile:  /opt/gcc-4_3-build/gcc/gcj .... /root/downloads/gcc-4_3-trunk/libjava/classpath/lib/java/lang/Class.class >/dev/null 2>&1
libtool: compile: mv -f "Class.o" "java/lang/Class.o"
echo /root/downloads/gcc-4_3-trunk/libjava/classpath/lib/java/lang/PosixProcess*.class > java/process-Posix.list
/bin/sh ./libtool --tag=GCJ --mode=compile ... java/process-Posix.deps @java/process-Posix.list
libtool: compile:  /opt/gcc-4_3-build/gcc/gcj .... java/process-Posix.deps @java/process-Posix.list 
libtool: compile: mv -f "process-Posix.o" "java/.libs/process-Posix.o"
mv: cannot stat `process-Posix.o': No such file or directory
make[3]: *** [java/process-Posix.lo] Error 1
make[3]: Leaving directory `/opt/gcc-4_3-build/i686-pc-linux-gnu/libjava'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/opt/gcc-4_3-build/i686-pc-linux-gnu/libjava'
make[1]: *** [all-target-libjava] Error 2
make[1]: Leaving directory `/opt/gcc-4_3-build'
make: *** [all] Error 2



Need to follow comment nine given above. 


# cp /root/downloads/libtool-1.5.22/libtool /opt/gcc-4_3-build/i686-pc-linux-gnu/libjava
# make

Working fine ...


Other notes:

See here for using "./libtool --tag=CXX --mode=compile" instead of "./libtool --tag=GCJ --mode=compile" to compile Java - the spec file needs fixing to do that (add "-fuse-boehm-gc"): http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31998

Subject: Re:  Make FAILURE in 4.3.0 - `CXXFLAGS' has changed error causes "libltdl: No such file or directory"

> libtool: compile: mv -f "process-Posix.o" "java/.libs/process-Posix.o"
> mv: cannot stat `process-Posix.o': No such file or directory

Had a similar error on hppa-unknown-linux-gnu in last night's build
but for a different file.

Dave

Fixed. We will need to fix PR 32098 for libjava.

Dave, it depends on the options used to configure Java, which files would be compiled and where the breakage occurs.

hjl@lucon.org says it is being fixed. If you can't wait then wget libtool as explained above, configure it, and drop it in hppa-unknown-linux-gnu/libjava.

I'm leaving the currect status of "RESOLVED FIXED" and I've changed this from blocker to normal since for the past few days gcc does not break during the make of libjava.

It would be good to use the same version of libtool in all of gcc. The upgrade of libtool in one part of gcc (with an old version) was part of the cause of these days of problems.