PATCH: PR libjava/32078: Update libtool in classpath

PATCH: PR libjava/32078: Update libtool in classpath

[H. J. Lu]

When libtool in gcc updated, libtool in classpath is out of sync
and classpath failed to build inside libjava. This patch copies
the new libtool from gcc toplevel with the modified libtool.m4:

http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01820.html

With this patch plus a kludge:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32078#c12

I can build libjava on Linux/x86-64.


H.J.

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

[H. J. Lu]

[-- Attachment #1: Type: text/plain, Size: 505 bytes --]

On Sun, May 27, 2007 at 11:22:03AM -0700, H. J. Lu wrote:
> When libtool in gcc updated, libtool in classpath is out of sync
> and classpath failed to build inside libjava. This patch copies
> the new libtool from gcc toplevel with the modified libtool.m4:
> 
> http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01820.html
> 
> With this patch plus a kludge:
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32078#c12
> 
> I can build libjava on Linux/x86-64.
> 

It helps when I enclose the patch :-).


H.J.

[-- Attachment #2: libjava-libtool-3.patch.bz2 --]
[-- Type: application/x-bzip2, Size: 162169 bytes --]

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

[Andrew Haley]

H. J. Lu writes:
 > On Sun, May 27, 2007 at 11:22:03AM -0700, H. J. Lu wrote:
 > > When libtool in gcc updated, libtool in classpath is out of sync
 > > and classpath failed to build inside libjava. This patch copies
 > > the new libtool from gcc toplevel with the modified libtool.m4:
 > > 
 > > http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01820.html
 > > 
 > > With this patch plus a kludge:
 > > 
 > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32078#c12
 > > 
 > > I can build libjava on Linux/x86-64.
 > 
 > It helps when I enclose the patch :-).

libtool in classpath is imported from upstream, so importing it here
would be a fork.  This needs to go to Classpath Patches <classpath-patches@gnu.org>.

Andrew.

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

[Andreas Schwab]

Andrew Haley <aph-gcc@littlepinkcloud.COM> writes:

> libtool in classpath is imported from upstream, so importing it here
> would be a fork.

The classpath copy in gcc has never used the imported libtool, but
rather a copy of the common gcc libtool.  See libjava/HACKING.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[Andrew Haley]

Andreas Schwab writes:
 > Andrew Haley <aph-gcc@littlepinkcloud.COM> writes:
 > 
 > > libtool in classpath is imported from upstream, so importing it here
 > > would be a fork.
 > 
 > The classpath copy in gcc has never used the imported libtool, but
 > rather a copy of the common gcc libtool.  See libjava/HACKING.

Ah, OK.  So, Classpath divergence isn't a problem, but divergence from
upstream libtool is.  

I'm not sure we should get into putting class files into autoconf
scripts, though.  I'm minded simply to accept HJ's patch rather than
do that.

Andrew.

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

[Matthias Klose]

H. J. Lu schrieb:

> 2007-05-27  H.J. Lu  <hongjiu.lu@intel.com>
>
> 	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.

  Matthias

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

[Paolo Bonzini]

> I'm not sure we should get into putting class files into autoconf
> scripts, though.  I'm minded simply to accept HJ's patch rather than
> do that.

If the libtool maintainers upstream appreciate our needs and are willing 
to do so, I think this is a much better solution.  The language spec 
files can play tricks with linker options, that could be of interest to 
the libtool configuration process.

Paolo

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

[H. J. Lu]

On Tue, May 29, 2007 at 12:45:53PM +0200, Matthias Klose wrote:
> H. J. Lu schrieb:
> 
> > 2007-05-27  H.J. Lu  <hongjiu.lu@intel.com>
> >
> > 	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?


H.J.

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

[Paolo Bonzini]

>>> 	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.

Paolo

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

[H. J. Lu]

On Tue, May 29, 2007 at 03:39:51PM +0200, Paolo Bonzini wrote:
> 
> >>>	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.

If I have to copy ltmain.sh, I don't think it makes senses not to
copy others. Otherwise, it will be very confusing.


H.J.

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

[Paolo Bonzini]

H. J. Lu wrote:
> On Tue, May 29, 2007 at 03:39:51PM +0200, Paolo Bonzini wrote:
>>>>> 	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.
> 
> If I have to copy ltmain.sh, I don't think it makes senses not to
> copy others. Otherwise, it will be very confusing.

Seems fine to me, but wait for Andrew Haley to approve that.

Paolo

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

[Andrew Haley]

Paolo Bonzini writes:
 > H. J. Lu wrote:
 > > On Tue, May 29, 2007 at 03:39:51PM +0200, Paolo Bonzini wrote:
 > >>>>> 	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.
 > > 
 > > If I have to copy ltmain.sh, I don't think it makes senses not to
 > > copy others. Otherwise, it will be very confusing.
 > 
 > Seems fine to me, but wait for Andrew Haley to approve that.

I'm happy if you are.  I just don't know enough about libtool to come
to any conclusion.  I do know that you can't compile Java source code
during configury.

Andrew.

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

[H. J. Lu]

On Tue, May 29, 2007 at 03:06:03PM +0100, Andrew Haley wrote:
> Paolo Bonzini writes:
>  > H. J. Lu wrote:
>  > > On Tue, May 29, 2007 at 03:39:51PM +0200, Paolo Bonzini wrote:
>  > >>>>> 	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.
>  > > 
>  > > If I have to copy ltmain.sh, I don't think it makes senses not to
>  > > copy others. Otherwise, it will be very confusing.
>  > 
>  > Seems fine to me, but wait for Andrew Haley to approve that.
> 
> I'm happy if you are.  I just don't know enough about libtool to come
> to any conclusion.  I do know that you can't compile Java source code
> during configury.

Can I compile and link Java byte code during configure?


H.J.

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

[Andrew Haley]

H. J. Lu writes:
 > On Tue, May 29, 2007 at 03:06:03PM +0100, Andrew Haley wrote:

 > > I'm happy if you are.  I just don't know enough about libtool to come
 > > to any conclusion.  I do know that you can't compile Java source code
 > > during configury.
 > 
 > Can I compile and link Java byte code during configure?

Yes, you can.

Andrew.

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

[H. J. Lu]

On Tue, May 29, 2007 at 03:27:03PM +0100, Andrew Haley wrote:
> H. J. Lu writes:
>  > On Tue, May 29, 2007 at 03:06:03PM +0100, Andrew Haley wrote:
> 
>  > > I'm happy if you are.  I just don't know enough about libtool to come
>  > > to any conclusion.  I do know that you can't compile Java source code
>  > > during configury.
>  > 
>  > Can I compile and link Java byte code during configure?
> 
> Yes, you can.

Do I need Java runtime library to create an executable from Java
byte code?


H.J.

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

[Andrew Haley]

H. J. Lu writes:
 > On Tue, May 29, 2007 at 03:27:03PM +0100, Andrew Haley wrote:
 > > H. J. Lu writes:
 > >  > On Tue, May 29, 2007 at 03:06:03PM +0100, Andrew Haley wrote:
 > > 
 > >  > > I'm happy if you are.  I just don't know enough about libtool to come
 > >  > > to any conclusion.  I do know that you can't compile Java source code
 > >  > > during configury.
 > >  > 
 > >  > Can I compile and link Java byte code during configure?
 > > 
 > > Yes, you can.
 > 
 > Do I need Java runtime library to create an executable from Java
 > byte code?

Certainly.  Any compile-and-link tests won't work.

Andrew.

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

[Paolo Bonzini]

>>  > > I'm happy if you are.  I just don't know enough about libtool to come
>>  > > to any conclusion.  I do know that you can't compile Java source code
>>  > > during configury.
>>  > 
>>  > Can I compile and link Java byte code during configure?
>>
>> Yes, you can.
> 
> Do I need Java runtime library to create an executable from Java
> byte code?

No, you don't.  You need to Java runtime library *in bytecode form*, but 
that's present under libjava/classpath/lib.

(BTW, it seems that we're talking about two patches.  1) Copying 
libtool.m4 to classpath -- that's fine.  2) Hacking around libtool.m4 to 
use gcc instead of gcj -- that's not.)

Paolo

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

[Andrew Haley]

Andrew Haley writes:
 > H. J. Lu writes:
 >  > On Tue, May 29, 2007 at 03:27:03PM +0100, Andrew Haley wrote:
 >  > > H. J. Lu writes:
 >  > >  > On Tue, May 29, 2007 at 03:06:03PM +0100, Andrew Haley wrote:
 >  > > 
 >  > >  > > I'm happy if you are.  I just don't know enough about libtool to come
 >  > >  > > to any conclusion.  I do know that you can't compile Java source code
 >  > >  > > during configury.
 >  > >  > 
 >  > >  > Can I compile and link Java byte code during configure?
 >  > > 
 >  > > Yes, you can.
 >  > 
 >  > Do I need Java runtime library to create an executable from Java
 >  > byte code?
 > 
 > Certainly.  Any compile-and-link tests won't work.

I'm sorry, I missed the "and link" part of your question.  Configury
tests of this kind really aren't going to work.  For things like tests
for PIC, it's pointless: gcj supports the same options as gcc.

Andrew.

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

[Andrew Haley]

Paolo Bonzini writes:
 > 
 > >>  > > I'm happy if you are.  I just don't know enough about libtool to come
 > >>  > > to any conclusion.  I do know that you can't compile Java source code
 > >>  > > during configury.
 > >>  > 
 > >>  > Can I compile and link Java byte code during configure?
 > >>
 > >> Yes, you can.
 > > 
 > > Do I need Java runtime library to create an executable from Java
 > > byte code?
 > 
 > No, you don't.

Yeah, you do.  Executables are all linked against libgcj, so you
really do require it.

Andrew.

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

[Paolo Bonzini]

>>  > > I'm happy if you are.  I just don't know enough about libtool to come
>>  > > to any conclusion.  I do know that you can't compile Java source code
>>  > > during configury.
>>  > 
>>  > Can I compile and link Java byte code during configure?
>>
>> Yes, you can.
> 
> Do I need Java runtime library to create an executable from Java
> byte code?

No, you don't.  You need to Java runtime library *in bytecode form*, but 
that's present under libjava/classpath/lib.

(BTW, it seems that we're talking about two patches.  1) Copying 
libtool.m4 to classpath -- that's fine.  2) Hacking around libtool.m4 to 
use gcc instead of gcj -- that's not.)

Paolo

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

[Paolo Bonzini]

>  > Certainly.  Any compile-and-link tests won't work.
> 
> I'm sorry, I missed the "and link" part of your question.  Configury
> tests of this kind really aren't going to work.  For things like tests
> for PIC, it's pointless: gcj supports the same options as gcc.

Then, does anybody know the very reason why all those tests are run 
repeatedly for each language?

Paolo

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

[Paolo Bonzini]

>>>> Certainly.  Any compile-and-link tests won't work.
>>> I'm sorry, I missed the "and link" part of your question.  Configury
>>> tests of this kind really aren't going to work.  For things like tests
>>> for PIC, it's pointless: gcj supports the same options as gcc.
>> Then, does anybody know the very reason why all those tests are run 
>> repeatedly for each language?
> 
> I will guess. It is because the C/C++/Java/Fortran/.. compilers may
> not come from the same gcc version or based on gcc at all.

Okay, so we have a problem.  Because the patch you are proposing will 
not be accepted in any way by upstream. :-(

Paolo

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

[H. J. Lu]

On Tue, May 29, 2007 at 04:49:11PM +0200, Paolo Bonzini wrote:
> 
> > > Certainly.  Any compile-and-link tests won't work.
> >
> >I'm sorry, I missed the "and link" part of your question.  Configury
> >tests of this kind really aren't going to work.  For things like tests
> >for PIC, it's pointless: gcj supports the same options as gcc.
> 
> Then, does anybody know the very reason why all those tests are run 
> repeatedly for each language?

I will guess. It is because the C/C++/Java/Fortran/.. compilers may
not come from the same gcc version or based on gcc at all.


H.J.

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

[Andrew Haley]

Paolo Bonzini writes:
 > 
 > >>>> Certainly.  Any compile-and-link tests won't work.
 > >>> I'm sorry, I missed the "and link" part of your question.  Configury
 > >>> tests of this kind really aren't going to work.  For things like tests
 > >>> for PIC, it's pointless: gcj supports the same options as gcc.
 > >> Then, does anybody know the very reason why all those tests are run 
 > >> repeatedly for each language?
 > > 
 > > I will guess. It is because the C/C++/Java/Fortran/.. compilers may
 > > not come from the same gcc version or based on gcc at all.
 > 
 > Okay, so we have a problem.  Because the patch you are proposing will 
 > not be accepted in any way by upstream. :-(

How come we are doing this *now*?  Why was it not a problem before,
and what has changed?

Andrew.

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

[H. J. Lu]

On Tue, May 29, 2007 at 05:06:45PM +0200, Paolo Bonzini wrote:
> 
> >>>>Certainly.  Any compile-and-link tests won't work.
> >>>I'm sorry, I missed the "and link" part of your question.  Configury
> >>>tests of this kind really aren't going to work.  For things like tests
> >>>for PIC, it's pointless: gcj supports the same options as gcc.
> >>Then, does anybody know the very reason why all those tests are run 
> >>repeatedly for each language?
> >
> >I will guess. It is because the C/C++/Java/Fortran/.. compilers may
> >not come from the same gcc version or based on gcc at all.
> 
> Okay, so we have a problem.  Because the patch you are proposing will 
> not be accepted in any way by upstream. :-(

Bulding an XXX language run-time library is a very special case. You
can't build an XXX language run-time library, assuming the XXX language
compiler is fully functional.  If upstream libtool can support it, it
is great. Otherwise, we have to do one of these 4:

1. Drop Java.
2. Drop libtool for libjava.
3. Hack libtool for libjava.
4. Hack libjava configure to work around the libtool problem.

I proposed #3 with a simple and straightforward work around. We may
have to keep it around forever.


H.J.

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

[H. J. Lu]

On Tue, May 29, 2007 at 04:09:22PM +0100, Andrew Haley wrote:
> Paolo Bonzini writes:
>  > 
>  > >>>> Certainly.  Any compile-and-link tests won't work.
>  > >>> I'm sorry, I missed the "and link" part of your question.  Configury
>  > >>> tests of this kind really aren't going to work.  For things like tests
>  > >>> for PIC, it's pointless: gcj supports the same options as gcc.
>  > >> Then, does anybody know the very reason why all those tests are run 
>  > >> repeatedly for each language?
>  > > 
>  > > I will guess. It is because the C/C++/Java/Fortran/.. compilers may
>  > > not come from the same gcc version or based on gcc at all.
>  > 
>  > Okay, so we have a problem.  Because the patch you are proposing will 
>  > not be accepted in any way by upstream. :-(
> 
> How come we are doing this *now*?  Why was it not a problem before,
> and what has changed?

The old libtool in gcc has been heavily hacked to support building
run-time libraries in gcc. The new libtool update removed most, if
not all, of those hacks, which got us here.


H.J.

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

[Andrew Haley]

H. J. Lu writes:
 > On Tue, May 29, 2007 at 05:06:45PM +0200, Paolo Bonzini wrote:
 > > 
 > > >>>>Certainly.  Any compile-and-link tests won't work.
 > > >>>I'm sorry, I missed the "and link" part of your question.  Configury
 > > >>>tests of this kind really aren't going to work.  For things like tests
 > > >>>for PIC, it's pointless: gcj supports the same options as gcc.
 > > >>Then, does anybody know the very reason why all those tests are run 
 > > >>repeatedly for each language?
 > > >
 > > >I will guess. It is because the C/C++/Java/Fortran/.. compilers may
 > > >not come from the same gcc version or based on gcc at all.
 > > 
 > > Okay, so we have a problem.  Because the patch you are proposing will 
 > > not be accepted in any way by upstream. :-(
 > 
 > Bulding an XXX language run-time library is a very special case. You
 > can't build an XXX language run-time library, assuming the XXX language
 > compiler is fully functional.  If upstream libtool can support it, it
 > is great. Otherwise, we have to do one of these 4:
 > 
 > 1. Drop Java.
 > 2. Drop libtool for libjava.
 > 3. Hack libtool for libjava.
 > 4. Hack libjava configure to work around the libtool problem.
 > 
 > I proposed #3 with a simple and straightforward work around. We may
 > have to keep it around forever.

Perhaps we do #3 now, with a view to doing #4 later.

Andrew.

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

[Andreas Schwab]

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.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[H. J. Lu]

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?


H.J.

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

[Maciej W. Rozycki]

On Tue, 29 May 2007, Andrew Haley wrote:

>  > Bulding an XXX language run-time library is a very special case. You
>  > can't build an XXX language run-time library, assuming the XXX language
>  > compiler is fully functional.  If upstream libtool can support it, it
>  > is great. Otherwise, we have to do one of these 4:
>  > 
>  > 1. Drop Java.
>  > 2. Drop libtool for libjava.
>  > 3. Hack libtool for libjava.
>  > 4. Hack libjava configure to work around the libtool problem.
>  > 
>  > I proposed #3 with a simple and straightforward work around. We may
>  > have to keep it around forever.
> 
> Perhaps we do #3 now, with a view to doing #4 later.

 FYI, I built libjava of GCC 4.1.1 with upstream libtool 1.5.22 
successfully a while ago with the patch as follows.  No changes required 
to libtool itself whatsoever.  Of course the patch is on my ever pending 
list of patches to submit, but given the version there would normally be 
no point to in its current form.

 Now given the issue discussed here, it may save somebody unnecessary 
work.  It applies almost successfully ;-) and the rejects do not seem to 
look terribly hopeless, so I guess with little effort it could get 
integrated.  I might do the work if this approach looked interesting, but 
I am afraid I may not be able to afford the resources to switch to HEAD 
for testing right now.

  Maciej

gcc-4.1.1-libjava-ac25.patch
diff -bup --recursive --new-file gcc-4.1.1.macro/libjava/configure.ac gcc-4.1.1/libjava/configure.ac
--- gcc-4.1.1.macro/libjava/configure.ac	2006-04-11 20:09:32.000000000 +0000
+++ gcc-4.1.1/libjava/configure.ac	2007-02-02 00:02:55.000000000 +0000
@@ -160,6 +160,8 @@ AC_ARG_ENABLE(libgcj-debug,
     LIBGCJDEBUG="enable"
   fi])
 
+AC_PATH_XTRA
+
 # Determine which AWT peer libraries to build
 AC_ARG_ENABLE(java-awt,
   AS_HELP_STRING([--enable-java-awt],
@@ -238,6 +240,55 @@ if test "$use_qt_awt" != yes; then
    echo gnu/java/awt/peer/qt >> standard.omit
 fi
 
+# Create it, so that compile/link tests don't fail
+test -f libgcj.spec || touch libgcj.spec
+
+# We must search the source tree for java.lang, since we still don't
+# have libgcj.jar nor java/lang/*.class
+GCJ_SAVE_CPPFLAGS=$CPPFLAGS
+GCJ_srcdir=`cd $srcdir && ${PWDCMD-pwd}`
+CPPFLAGS="$CPPFLAGS -Wno-deprecated -I`${PWDCMD-pwd}` -I$GCJ_srcdir -I$GCJ_srcdir/classpath -I$GCJ_srcdir/classpath/external/w3c_dom -I$GCJ_srcdir/classpath/external/sax"
+
+# Since some classes depend on this one, we need its source available
+# before we can do any GCJ compilation test :-(
+if test ! -f gnu/classpath/Configuration.java; then
+  test -d gnu || mkdir gnu
+  test -d gnu/classpath || mkdir gnu/classpath
+  # Note that it is not crucial that all the values here be correct.
+  sed -e "s,@prefix@,$prefix," \
+      -e "s,@VERSION@,$VERSION," \
+      -e "s,@LIBDEBUG@,false," \
+      -e "s,@INIT_LOAD_LIBRARY@,false," \
+      -e "s,@@,$LIBGCJDEBUG," \
+      -e "s,@default_toolkit@,$TOOLKIT," \
+      -e "s,@JAVA_LANG_SYSTEM_EXPLICIT_INITIALIZATION@,false," \
+      -e "s,@GTK_CAIRO_ENABLED@,false," \
+	< $srcdir/classpath/gnu/classpath/Configuration.java.in \
+	> gnu/classpath/Configuration.java
+  # We do not want to redirect the output of the grep below to /dev/null,
+  # but we add /dev/null to the input list so that grep will print the
+  # filename of Configuration.java in case it finds any matches.
+  if grep '@.*@' gnu/classpath/Configuration.java /dev/null; then
+    AC_MSG_ERROR([configure.ac is missing the substitutions above])
+  fi
+fi
+
+# Only use libltdl for non-newlib builds.
+if test "x${with_newlib}" = "x" || test "x${with_newlib}" = "xno"; then
+   AC_LIBLTDL_CONVENIENCE
+   AC_LIBTOOL_DLOPEN
+   DIRLTDL=libltdl
+   AC_DEFINE(USE_LTDL, 1, [Define if libltdl is in use.])
+   # Sigh.  Libtool's macro doesn't do the right thing.
+   INCLTDL="-I\$(top_srcdir)/libltdl $INCLTDL"
+   # FIXME: this is a hack.
+   sub_auxdir="`cd $ac_aux_dir && ${PWDCMD-pwd}`"
+   ac_configure_args="$ac_configure_args --with-auxdir=$sub_auxdir"
+fi
+AC_SUBST(INCLTDL)
+AC_SUBST(LIBLTDL)
+AC_SUBST(DIRLTDL)
+
 if test -z "${with_multisubdir}"; then
    builddotdot=.
 else
@@ -313,9 +364,6 @@ esac
 AC_SUBST(GCJH)
 AC_SUBST(ZIP)
 
-# Create it, so that compile/link tests don't fail
-test -f libgcj.spec || touch libgcj.spec
-
 
 
 # Set up to configure Classpath.
@@ -345,24 +393,15 @@ dnl gjdoc?
 dnl gtk-cairo -- just export here...
 dnl --enable-regen-headers?
 
-# Only use libltdl for non-newlib builds.
-if test "x${with_newlib}" = "x" || test "x${with_newlib}" = "xno"; then
-   AC_LIBLTDL_CONVENIENCE
-   AC_LIBTOOL_DLOPEN
-   DIRLTDL=libltdl
-   AC_DEFINE(USE_LTDL, 1, [Define if libltdl is in use.])
-   # Sigh.  Libtool's macro doesn't do the right thing.
-   INCLTDL="-I\$(top_srcdir)/libltdl $INCLTDL"
-   # FIXME: this is a hack.
-   sub_auxdir="`cd $ac_aux_dir && ${PWDCMD-pwd}`"
-   ac_configure_args="$ac_configure_args --with-auxdir=$sub_auxdir"
-fi
-AC_SUBST(INCLTDL)
-AC_SUBST(LIBLTDL)
-AC_SUBST(DIRLTDL)
 AC_PROG_LIBTOOL
 AM_PROG_GCJ
 AM_PROG_CC_C_O
+LT_AC_PROG_GCJ
+
+# Now remove it.
+rm -f gnu/classpath/Configuration.java
+
+CPPFLAGS=$GCJ_SAVE_CPPFLAGS
 
 AC_CONFIG_SUBDIRS(classpath libltdl)
 
@@ -676,8 +715,6 @@ AC_SUBST(ZLIBSPEC)
 ZLIBTESTSPEC=
 AC_SUBST(ZLIBTESTSPEC)
 
-AC_PATH_XTRA
-
 # determine whether to enable the cairo GTK Graphics2D backend
 AC_ARG_ENABLE(gtk-cairo,
   AS_HELP_STRING([--enable-gtk-cairo],
@@ -1165,42 +1202,6 @@ case $build in
 esac
 AC_SUBST(CLASSPATH_SEPARATOR)
 
-# We must search the source tree for java.lang, since we still don't
-# have libgcj.jar nor java/lang/*.class
-GCJ_SAVE_CPPFLAGS=$CPPFLAGS
-CPPFLAGS="$CPPFLAGS -I`${PWDCMD-pwd}` -I`cd $srcdir && ${PWDCMD-pwd}`"
-
-# Since some classes depend on this one, we need its source available
-# before we can do any GCJ compilation test :-(
-if test ! -f gnu/classpath/Configuration.java; then
-  test -d gnu || mkdir gnu
-  test -d gnu/classpath || mkdir gnu/classpath
-  # Note that it is not crucial that all the values here be correct.
-  sed -e "s,@prefix@,$prefix," \
-      -e "s,@VERSION@,$VERSION," \
-      -e "s,@LIBDEBUG@,false," \
-      -e "s,@INIT_LOAD_LIBRARY@,false," \
-      -e "s,@@,$LIBGCJDEBUG," \
-      -e "s,@default_toolkit@,$TOOLKIT," \
-      -e "s,@JAVA_LANG_SYSTEM_EXPLICIT_INITIALIZATION@,false," \
-      -e "s,@GTK_CAIRO_ENABLED@,false," \
-	< $srcdir/classpath/gnu/classpath/Configuration.java.in \
-	> gnu/classpath/Configuration.java
-  # We do not want to redirect the output of the grep below to /dev/null,
-  # but we add /dev/null to the input list so that grep will print the
-  # filename of Configuration.java in case it finds any matches.
-  if grep '@.*@' gnu/classpath/Configuration.java /dev/null; then
-    AC_MSG_ERROR([configure.ac is missing the substitutions above])
-  fi
-fi
-
-LT_AC_PROG_GCJ
-
-# Now remove it.
-rm -f gnu/classpath/Configuration.java
-
-CPPFLAGS=$GCJ_SAVE_CPPFLAGS
-
 AC_CHECK_SIZEOF(void *)
 
 AC_C_BIGENDIAN

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

[Andreas Schwab]

"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.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[H. J. Lu]

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.

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

[Andreas Schwab]

"H. J. Lu" <hjl@lucon.org> writes:

> 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.

Not needed, just mark the change GCJ LOCAL.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[H. J. Lu]

On Tue, May 29, 2007 at 07:37:25PM +0200, Andreas Schwab wrote:
> "H. J. Lu" <hjl@lucon.org> writes:
> 
> > 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.
> 
> Not needed, just mark the change GCJ LOCAL.
> 

From libjava/HACKING:

- Use auto* to create configure, Makefile.in, etc
  Make sure you have Automake 1.9.6 installed. Exactly that version!
  You have to make sure to use the gcc libtool.m4 and gcc lt* scripts
  cd .../classpath
  cp ../../lt* .
  cp ../../config.sub ../../config.guess .
  aclocal -I m4 -I ../.. -I ../../config
  autoconf
  autoheader
  automake
  rm -rf autom4te.cache
  cd ..
  scripts/makemake.tcl > sources.am
  automake

There is no need to add AC_CONFIG_AUX_DIR(../..) if the above is
followed.


H.J.

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

[Tom Tromey]

>>>>> "H.J." == H J Lu <hjl@lucon.org> writes:

H.J.> There is no need to add AC_CONFIG_AUX_DIR(../..) if the above is
H.J.> followed.

If the AC_CONFIG_AUX_DIR approach works, then let's use that.
This is better because it means future libtool upgrades won't require
extra hacks for libjava/classpath, and because it means less work when
importing a new Classpath.

If it doesn't work, let's copy the needed files there.

Can you try this?

Tom

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

[H. J. Lu]

On Tue, May 29, 2007 at 11:33:24AM -0600, Tom Tromey wrote:
> >>>>> "H.J." == H J Lu <hjl@lucon.org> writes:
> 
> H.J.> There is no need to add AC_CONFIG_AUX_DIR(../..) if the above is
> H.J.> followed.
> 
> If the AC_CONFIG_AUX_DIR approach works, then let's use that.
> This is better because it means future libtool upgrades won't require
> extra hacks for libjava/classpath, and because it means less work when
> importing a new Classpath.
> 
> If it doesn't work, let's copy the needed files there.
> 
> Can you try this?
> 

This patch + my libtool.m4 hack work for me on Linux/x86-64 with
"make", "make check" and "make install".

I didn't update libjava/HACKING nor touch lt* files in classpath since
I don't know much about classpath. Someone who is familiar with
classpath should look into them.


H.J.
---
2007-05-29  H.J. Lu  <hongjiu.lu@intel.com>

	PR libjava/32078
	* configure.ac: Add AC_CONFIG_AUX_DIR(../..).
	* aclocal.m4: Regenerated.
	* configure: Likewise.
	* Makefile.in: Likewise.

--- libjava/classpath/configure.ac.libtool	2007-03-19 15:03:07.000000000 -0700
+++ libjava/classpath/configure.ac	2007-05-29 11:30:46.000000000 -0700
@@ -9,6 +9,10 @@ dnl define([AC_CACHE_SAVE], )dnl
 AC_INIT([GNU Classpath],[0.94-pre],[classpath@gnu.org],[classpath])
 AC_CONFIG_SRCDIR(java/lang/System.java)
 
+dnl GCJ LOCAL
+AC_CONFIG_AUX_DIR(../..)
+dnl END GCJ LOCAL
+
 AC_CANONICAL_TARGET
 
 dnl GCJ LOCAL

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

[Paolo Bonzini]

> This patch + my libtool.m4 hack work for me on Linux/x86-64 with
> "make", "make check" and "make install".
> 
> I didn't update libjava/HACKING nor touch lt* files in classpath since
> I don't know much about classpath. Someone who is familiar with
> classpath should look into them.

I'll let the Java maintainers (hi Tom :-) remark about this.

Paolo

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

[Tom Tromey]

>>>>> "H.J." == H J Lu <hjl@lucon.org> writes:

H.J.> This patch + my libtool.m4 hack work for me on Linux/x86-64 with
H.J.> "make", "make check" and "make install".

I suppose someone else will have to review the libtool.m4 patch.
I'd appreciate it if this were done quickly.  libjava hasn't built for
several days now.

Your change in classpath is ok.  Thank you.

H.J.> I didn't update libjava/HACKING nor touch lt* files in classpath since
H.J.> I don't know much about classpath. Someone who is familiar with
H.J.> classpath should look into them.

I will look at this once I can build things again.

Tom

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

[H. J. Lu]

On Wed, May 30, 2007 at 11:01:00AM -0600, Tom Tromey wrote:
> >>>>> "H.J." == H J Lu <hjl@lucon.org> writes:
> 
> H.J.> This patch + my libtool.m4 hack work for me on Linux/x86-64 with
> H.J.> "make", "make check" and "make install".
> 
> I suppose someone else will have to review the libtool.m4 patch.
> I'd appreciate it if this were done quickly.  libjava hasn't built for
> several days now.
> 
> Your change in classpath is ok.  Thank you.

My change in classpath won't work without my libtool.m4 change. I
will check in my libtool.m4 change to enable libjava build again. We
can always back it out later when a better solution is found.


H.J.

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

[Tom Tromey]

>>>>> "H.J." == H J Lu <hjl@lucon.org> writes:

>> Your change in classpath is ok.  Thank you.

H.J.> My change in classpath won't work without my libtool.m4 change. I
H.J.> will check in my libtool.m4 change to enable libjava build again. We
H.J.> can always back it out later when a better solution is found.

I'm sympathetic to this but it isn't how GCC development works.
Unfortunately, I think we have to keep things broken until someone
reviews the change.  IMO it definitely doesn't qualify as obvious.

Your classpath change doesn't make things worse at any rate.
You can put it in now if you like.

Tom

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

[Peter O'Gorman]

On Wed, 2007-05-30 at 10:37 -0700, H. J. Lu wrote:
> On Wed, May 30, 2007 at 11:01:00AM -0600, Tom Tromey wrote:
> > >>>>> "H.J." == H J Lu <hjl@lucon.org> writes:
> > 
> > H.J.> This patch + my libtool.m4 hack work for me on Linux/x86-64 with
> > H.J.> "make", "make check" and "make install".
> > 
> > I suppose someone else will have to review the libtool.m4 patch.
> > I'd appreciate it if this were done quickly.  libjava hasn't built for
> > several days now.
> > 
> > Your change in classpath is ok.  Thank you.
> 
> My change in classpath won't work without my libtool.m4 change. I
> will check in my libtool.m4 change to enable libjava build again. We
> can always back it out later when a better solution is found.

I don't see the need to fork libtool.m4, if you can't get aclocal to
work (I couldn't either when I tried just now) just put this in
configure.ac ( or in a separate file and m4_include it):

m4_pushdef([_LT_LANG_GCJ_CONFIG],
[
# Source file extension for Java test sources.
ac_ext=c

# Object file extension for compiled Java test sources.
objext=o
_LT_TAGVAR(objext, $1)=$objext

# Code to be used in simple compile tests
lt_simple_compile_test_code="int some_java_variable = 0;"
# Code to be used in simple link tests
lt_simple_link_test_code='int main(){return(0);}'

# ltmain only uses $CC for tagged configurations so make sure $CC is
set.
_LT_TAG_COMPILER

# save warnings/boilerplate of simple test code
_LT_COMPILER_BOILERPLATE
_LT_LINKER_BOILERPLATE

# Allow CC to be a program name with arguments.
compiler=$CC
_LT_TAGVAR(compiler, $1)=$CC
_LT_CC_BASENAME([$compiler])

# GCJ did not exist at the time GCC didn't implicitly link libc in.
_LT_TAGVAR(archive_cmds_need_lc, $1)=no

_LT_TAGVAR(old_archive_cmds, $1)=$old_archive_cmds

## CAVEAT EMPTOR:
## There is no encapsulation within the following macros, do not change
## the running order or otherwise move them around unless you know
exactly
## what you are doing...
if test -n "$compiler"; then
  _LT_COMPILER_NO_RTTI($1)
  _LT_COMPILER_PIC($1)
  _LT_COMPILER_C_O($1)
  _LT_COMPILER_FILE_LOCKS($1)
  _LT_LINKER_SHLIBS($1)
  _LT_SYS_DYNAMIC_LINKER($1)
  _LT_LINKER_HARDCODE_LIBPATH($1)

  _LT_CONFIG($1)
fi

AC_LANG_RESTORE
])# _LT_LANG_GCJ_CONFIG

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

[H. J. Lu]

On Wed, May 30, 2007 at 02:32:03PM -0500, Peter O'Gorman wrote:
> On Wed, 2007-05-30 at 10:37 -0700, H. J. Lu wrote:
> > On Wed, May 30, 2007 at 11:01:00AM -0600, Tom Tromey wrote:
> > > >>>>> "H.J." == H J Lu <hjl@lucon.org> writes:
> > > 
> > > H.J.> This patch + my libtool.m4 hack work for me on Linux/x86-64 with
> > > H.J.> "make", "make check" and "make install".
> > > 
> > > I suppose someone else will have to review the libtool.m4 patch.
> > > I'd appreciate it if this were done quickly.  libjava hasn't built for
> > > several days now.
> > > 
> > > Your change in classpath is ok.  Thank you.
> > 
> > My change in classpath won't work without my libtool.m4 change. I
> > will check in my libtool.m4 change to enable libjava build again. We
> > can always back it out later when a better solution is found.
> 
> I don't see the need to fork libtool.m4, if you can't get aclocal to
> work (I couldn't either when I tried just now) just put this in
> configure.ac ( or in a separate file and m4_include it):
> 
> m4_pushdef([_LT_LANG_GCJ_CONFIG],
> [

Have you tried it? Does it work? Do you have a patch I can try?

When I tried it, it didn't work and the one in libtool.m4 was used.
I think the order of 2 _LT_LANG_GCJ_CONFIGs is important. I couldn't
get it right.


H.J.

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

[Paolo Bonzini]

[-- Attachment #1: Type: text/plain, Size: 598 bytes --]


> H.J.> My change in classpath won't work without my libtool.m4 change. I
> H.J.> will check in my libtool.m4 change to enable libjava build again. We
> H.J.> can always back it out later when a better solution is found.
> 
> I'm sympathetic to this but it isn't how GCC development works.
> Unfortunately, I think we have to keep things broken until someone
> reviews the change.  IMO it definitely doesn't qualify as obvious.

No big deal.  Here's the patch to fix it locally.

My apologies for the prolonged breakage, and thanks to Andrew Haley for 
making the problem more clear to me.

Paolo

[-- Attachment #2: pr32098-proper-fix.patch --]
[-- Type: text/plain, Size: 3068 bytes --]

2003-05-31  Paolo Bonzini  <bonzini@gnu.org>

	PR libjava/32098
	* libtool.m4: Revert previous change.
	* ltgcc.m4: Put it here.

libjava:
2003-05-31  Paolo Bonzini  <bonzini@gnu.org>

	PR libjava/32098
	* aclocal.m4: Regenerate.
	* configure: Regenerate.

Index: libtool.m4
===================================================================
--- libtool.m4	(revision 125214)
+++ libtool.m4	(working copy)
@@ -6757,14 +6757,9 @@ _LT_TAG_COMPILER
 _LT_COMPILER_BOILERPLATE
 _LT_LINKER_BOILERPLATE
 
-# We can't call gcj to test gcj features when building libjava in gcc
-# since gcj may depend on ecj1 which may not be available yet.  We use
-# gcc to test gcj features.
-ac_ext=c
-lt_simple_compile_test_code="int some_variable = 0;"
-lt_simple_link_test_code='int main(){return(0);}'
-
 # Allow CC to be a program name with arguments.
+lt_save_CC="$CC"
+CC=${GCJ-"gcj"}
 compiler=$CC
 _LT_TAGVAR(compiler, $1)=$CC
 _LT_CC_BASENAME([$compiler])
@@ -6791,6 +6786,7 @@ if test -n "$compiler"; then
 fi
 
 AC_LANG_RESTORE
+CC="$lt_save_CC"
 ])# _LT_LANG_GCJ_CONFIG
 
 
Index: ltgcc.m4
===================================================================
--- ltgcc.m4	(revision 0)
+++ ltgcc.m4	(revision 0)
@@ -0,0 +1,60 @@
+# _LT_LANG_GCJ_CONFIG([TAG])
+# --------------------------
+# Ensure that the configuration variables for the GNU Java Compiler compiler
+# are suitably defined.  These variables are subsequently used by _LT_CONFIG
+# to write the compiler configuration to `libtool'.  Locally modified to
+# run its tests on C programs, because we cannot link Java programs until
+# we have finished building libjava.
+AC_DEFUN([_LT_LANG_GCJ_CONFIG],
+[AC_REQUIRE([LT_PROG_GCJ])dnl
+AC_LANG_SAVE
+
+# Source file extension for Java test sources.
+ac_ext=c
+
+# Object file extension for compiled Java test sources.
+objext=o
+_LT_TAGVAR(objext, $1)=$objext
+
+# Code to be used in simple compile tests
+lt_simple_compile_test_code="int some_variable = 0;"
+
+# Code to be used in simple link tests
+lt_simple_link_test_code='int main(){return(0);}'
+
+# ltmain only uses $CC for tagged configurations so make sure $CC is set.
+_LT_TAG_COMPILER
+
+# save warnings/boilerplate of simple test code
+_LT_COMPILER_BOILERPLATE
+_LT_LINKER_BOILERPLATE
+
+# Allow CC to be a program name with arguments.
+compiler=$CC
+_LT_TAGVAR(compiler, $1)=$CC
+_LT_CC_BASENAME([$compiler])
+
+# GCJ did not exist at the time GCC didn't implicitly link libc in.
+_LT_TAGVAR(archive_cmds_need_lc, $1)=no
+
+_LT_TAGVAR(old_archive_cmds, $1)=$old_archive_cmds
+
+## CAVEAT EMPTOR:
+## There is no encapsulation within the following macros, do not change
+## the running order or otherwise move them around unless you know exactly
+## what you are doing...
+if test -n "$compiler"; then
+  _LT_COMPILER_NO_RTTI($1)
+  _LT_COMPILER_PIC($1)
+  _LT_COMPILER_C_O($1)
+  _LT_COMPILER_FILE_LOCKS($1)
+  _LT_LINKER_SHLIBS($1)
+  _LT_SYS_DYNAMIC_LINKER($1)
+  _LT_LINKER_HARDCODE_LIBPATH($1)
+
+  _LT_CONFIG($1)
+fi
+
+_LT_TAGVAR(compiler, $1)=${GCJ-gcj}
+AC_LANG_RESTORE
+])# _LT_LANG_GCJ_CONFIG

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

[Tom Tromey]

>>>>> "Paolo" == Paolo Bonzini <bonzini@gnu.org> writes:

Paolo> My apologies for the prolonged breakage, and thanks to Andrew Haley
Paolo> for making the problem more clear to me.

Thanks Paolo.

Tom

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

[Charles Wilson]

On Tue, 29 May 2007 12:16:54 -0400, "Charles Wilson" said:
> 
> > >    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.
> 
> Or, use AC_CONFIG_AUX_DIR(<relative path to toplevel>) in configure.ac.

sorry for the dup.  You'd think I would have learned by now not to reply
to an individual message before reading the rest of the thread...

--
Chuck

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

[Charles Wilson]

> >    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.

Or, use AC_CONFIG_AUX_DIR(<relative path to toplevel>) in configure.ac.

--
Chuck