------- 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 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
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32078
