This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]