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]

Re: PATCH: PR libjava/32078: Update libtool in classpath


On Tue, May 29, 2007 at 07:07:39PM +0200, Andreas Schwab wrote:
> "H. J. Lu" <hjl@lucon.org> writes:
> 
> > On Tue, May 29, 2007 at 05:44:37PM +0200, Andreas Schwab wrote:
> >> Paolo Bonzini <bonzini@gnu.org> writes:
> >> 
> >> >>>> 	PR libjava/32078
> >> >>>> 	* ltmain.sh: Update from gcc toplevel.
> >> >>>> 	* libtool.m4: New. Copied from from gcc toplevel.
> >> >>>> 	* ltsugar.m4: Likewise.
> >> >>>> 	* ltversion.m4: Likewise.
> >> >>>> 	* ltoptions.m4: Likewise.
> >> >>> why copy these? libjava/HACKING mentions to use -I flags to use them from the
> >> >>> toplevel directory.
> >> >>
> >> >> I think ltmain.sh in classpath was used.  If it is true, will
> >> >> -I use ltmain.sh from the toplevel directory?
> >> >
> >> > No, you are right that you have to copy ltmain.sh at least.
> >> 
> >> AC_CONFIG_AUX_DIR(../..) should work too.
> >> 
> >
> > Will it work with the standalone classpath?
> 
> That would be local change, of course.

It is different from libjava/HACKING and the current libtool files
in classpath in libjava were copied from the old libtool in gcc
toplevel directory. Assuming it works, we have 2 choices:

1. Add AC_CONFIG_AUX_DIR(../..) to configure.ac in classpath:
   a. Update libjava/HACKING.
   b. Undo the libtool changes in classpath.
   d. Regenerate autoconf/automake files.
2. Copy the new libtool files in gcc toplevel directory and
regenerate autoconf/automake files.


H.J.


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