[Bug other/32078] Make FAILURE in 4.3.0 - `CXXFLAGS' has changed error causes "libltdl: No such file or directory"
--- Comment #22 from rob1weld at aol dot com 2007-06-05 17:28 --- 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. -- rob1weld at aol dot com changed: What|Removed |Added Severity|blocker |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32078
[Bug other/32078] Make FAILURE in 4.3.0 - `CXXFLAGS' has changed error causes "libltdl: No such file or directory"
--- Comment #21 from rob1weld at aol dot com 2007-05-30 03:34 --- Dave, it depends on the options used to configure Java, which files would be compiled and where the breakage occurs. [EMAIL PROTECTED] 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32078
[Bug other/32078] Make FAILURE in 4.3.0 - `CXXFLAGS' has changed error causes "libltdl: No such file or directory"
--- Comment #20 from hjl at lucon dot org 2007-05-30 00:46 --- Fixed. We will need to fix PR 32098 for libjava. -- hjl at lucon dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32078
[Bug other/32078] Make FAILURE in 4.3.0 - `CXXFLAGS' has changed error causes "libltdl: No such file or directory"
--- Comment #19 from dave at hiauly1 dot hia dot nrc dot ca 2007-05-30 00:07 --- 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 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32078
[Bug other/32078] Make FAILURE in 4.3.0 - `CXXFLAGS' has changed error causes "libltdl: No such file or directory"
--- Comment #18 from rob1weld at aol dot com 2007-05-29 23:47 --- 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-
[Bug other/32078] Make FAILURE in 4.3.0 - `CXXFLAGS' has changed error causes "libltdl: No such file or directory"
--- Comment #17 from rob1weld at aol dot com 2007-05-29 00:28 --- # 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32078
[Bug other/32078] Make FAILURE in 4.3.0 - `CXXFLAGS' has changed error causes "libltdl: No such file or directory"
--- 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.0 -0700 +++ libjava/confi
[Bug other/32078] Make FAILURE in 4.3.0 - `CXXFLAGS' has changed error causes "libltdl: No such file or directory"
--- Comment #15 from bonzini at gnu dot org 2007-05-28 06:38 --- 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 <[EMAIL PROTECTED]> PR bootstrap/32078 * configure.ac: Include confsubdir.m4. * configure: Regenerate. Modified: trunk/libjava/ChangeLog trunk/libjava/configure trunk/libjava/configure.ac -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32078
[Bug other/32078] Make FAILURE in 4.3.0 - `CXXFLAGS' has changed error causes "libltdl: No such file or directory"
--- Comment #14 from hjl at lucon dot org 2007-05-28 01:35 --- This patch allows libjava to build: http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01843.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32078
[Bug other/32078] Make FAILURE in 4.3.0 - `CXXFLAGS' has changed error causes "libltdl: No such file or directory"
--- Comment #13 from hjl at lucon dot org 2007-05-27 18:50 --- 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 -- hjl at lucon dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2007- ||05/msg01824.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32078
[Bug other/32078] Make FAILURE in 4.3.0 - `CXXFLAGS' has changed error causes "libltdl: No such file or directory"
--- Comment #12 from hjl at lucon dot org 2007-05-27 17:59 --- Created an attachment (id=13617) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13617&action=view) A kludge to work around the autoconf bug. This is a kludge which allows me to go further in libjava build. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32078
[Bug other/32078] Make FAILURE in 4.3.0 - `CXXFLAGS' has changed error causes "libltdl: No such file or directory"
--- Comment #11 from hjl at lucon dot org 2007-05-27 07:24 --- (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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32078
[Bug other/32078] Make FAILURE in 4.3.0 - `CXXFLAGS' has changed error causes "libltdl: No such file or directory"
--- Comment #10 from rob1weld at aol dot com 2007-05-27 07:06 --- 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 passes2538 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 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32078
[Bug other/32078] Make FAILURE in 4.3.0 - `CXXFLAGS' has changed error causes "libltdl: No such file or directory"
--- Comment #9 from rob1weld at aol dot com 2007-05-26 22:51 --- 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) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32078
[Bug other/32078] Make FAILURE in 4.3.0 - `CXXFLAGS' has changed error causes "libltdl: No such file or directory"
--- Comment #8 from rob1weld at aol dot com 2007-05-26 17:40 ---
>> 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.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32078
[Bug other/32078] Make FAILURE in 4.3.0 - `CXXFLAGS' has changed error causes "libltdl: No such file or directory"
--- Comment #7 from howarth at nitro dot med dot uc dot edu 2007-05-26 02:43 --- >From http://gcc.gnu.org/viewcvs?view=rev&revision=125032, it appears that libjava/libltdl was omitted from the regeneration as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32078
[Bug other/32078] Make FAILURE in 4.3.0 - `CXXFLAGS' has changed error causes "libltdl: No such file or directory"
--- Comment #6 from rob1weld at aol dot com 2007-05-25 15:59 --- 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 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32078
[Bug other/32078] Make FAILURE in 4.3.0 - `CXXFLAGS' has changed error causes "libltdl: No such file or directory"
--- Comment #5 from nathan at gcc dot gnu dot org 2007-05-25 15:40 --- 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? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32078
[Bug other/32078] Make FAILURE in 4.3.0 - `CXXFLAGS' has changed error causes "libltdl: No such file or directory"
--- Comment #4 from rob1weld at aol dot com 2007-05-25 15:39 --- >> 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32078
[Bug other/32078] Make FAILURE in 4.3.0 - `CXXFLAGS' has changed error causes "libltdl: No such file or directory"
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-05-25 15:17 --- Do either of you read the list? http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01665.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32078
[Bug other/32078] Make FAILURE in 4.3.0 - `CXXFLAGS' has changed error causes "libltdl: No such file or directory"
--- Comment #2 from hjl at lucon dot org 2007-05-25 13:31 --- I saw it with revision 125032 on a quad-core Linux/x86-64 with "make -j4". -- hjl at lucon dot org changed: What|Removed |Added CC||hjl at lucon dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|i686-pc-linux-gnu | GCC host triplet|i686-pc-linux-gnu | GCC target triplet|i686-pc-linux-gnu | Last reconfirmed|-00-00 00:00:00 |2007-05-25 13:31:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32078
[Bug other/32078] Make FAILURE in 4.3.0 - `CXXFLAGS' has changed error causes "libltdl: No such file or directory"
--- Comment #1 from rob1weld at aol dot com 2007-05-25 10:49 --- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32078
