This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
PATCH: PR libjava/32098: New libtool doesn't support libjava
- From: "Charles Wilson" <libtool at cwilson dot fastmail dot fm>
- To: gcc-patches at gcc dot gnu dot org
- Date: Sun, 27 May 2007 16:20:02 -0400
- Subject: PATCH: PR libjava/32098: New libtool doesn't support libjava
H.J. Lu wrote:
> New libtool calls gcj to test gcj features. However, gcj isn't
> fully functional when building libjava since ecj1 isn't available.
> As the result, libtool created for libjava isn't really correct.
> This patch uses gcc to test gcj features like PIC and "-c -o".
Is there any way to achieve this result without forking libtool? [1,2,3]
Perhaps by using some of the techniques in libstdc++'s acinclude?
http://gcc.gnu.org/viewcvs/trunk/libstdc%2B%2B-v3/acinclude.m4?revision=124896&view=markup
[1] especially as Steve just got finished resyncing it with the official
libtool sources
[2] changes in toplevel .m4 files require regenerating every Makefile.in
and configure script in all of gcc/ and src/ trees
[3] finally, quoting myself from
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01654.html
> However, wasn't the point of using ToT libtool: to _avoid_ haring off
> with quick-n-dirty [*] local patches -- in effect, forking libtool?
> Instead of fixing gcc's local copy, shouldn't this fix -- or a better
> one -- instead be submitted to libtool, and then gcc can resync?
--
Chuck