[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 #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