* PATCH: PR libjava/32078: Update libtool in classpath
@ 2007-05-27 18:25 H. J. Lu
2007-05-27 18:53 ` H. J. Lu
[not found] ` <20070527182317.GA21785@lucon.org>
0 siblings, 2 replies; 46+ messages in thread
From: H. J. Lu @ 2007-05-27 18:25 UTC (permalink / raw)
To: gcc-patches; +Cc: java-patches
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.
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: PATCH: PR libjava/32078: Update libtool in classpath
2007-05-27 18:25 PATCH: PR libjava/32078: Update libtool in classpath H. J. Lu
@ 2007-05-27 18:53 ` H. J. Lu
[not found] ` <20070527182317.GA21785@lucon.org>
1 sibling, 0 replies; 46+ messages in thread
From: H. J. Lu @ 2007-05-27 18:53 UTC (permalink / raw)
To: gcc-patches; +Cc: java-patches
[-- 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 --]
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: PATCH: PR libjava/32078: Update libtool in classpath
[not found] ` <20070527182317.GA21785@lucon.org>
@ 2007-05-29 10:25 ` Andrew Haley
2007-05-29 10:46 ` Andreas Schwab
2007-05-29 12:17 ` Matthias Klose
1 sibling, 1 reply; 46+ messages in thread
From: Andrew Haley @ 2007-05-29 10:25 UTC (permalink / raw)
To: H. J. Lu; +Cc: gcc-patches, java-patches, Classpath Patches
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.
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: PATCH: PR libjava/32078: Update libtool in classpath
2007-05-29 10:25 ` Andrew Haley
@ 2007-05-29 10:46 ` Andreas Schwab
2007-05-29 10:48 ` Andrew Haley
0 siblings, 1 reply; 46+ messages in thread
From: Andreas Schwab @ 2007-05-29 10:46 UTC (permalink / raw)
To: Andrew Haley; +Cc: H. J. Lu, gcc-patches, java-patches, Classpath Patches
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."
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: PATCH: PR libjava/32078: Update libtool in classpath
2007-05-29 10:46 ` Andreas Schwab
@ 2007-05-29 10:48 ` Andrew Haley
2007-05-29 13:10 ` Paolo Bonzini
0 siblings, 1 reply; 46+ messages in thread
From: Andrew Haley @ 2007-05-29 10:48 UTC (permalink / raw)
To: Andreas Schwab; +Cc: H. J. Lu, gcc-patches, java-patches, Classpath Patches
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.
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: PATCH: PR libjava/32078: Update libtool in classpath
[not found] ` <20070527182317.GA21785@lucon.org>
2007-05-29 10:25 ` Andrew Haley
@ 2007-05-29 12:17 ` Matthias Klose
2007-05-29 13:43 ` H. J. Lu
1 sibling, 1 reply; 46+ messages in thread
From: Matthias Klose @ 2007-05-29 12:17 UTC (permalink / raw)
To: H. J. Lu; +Cc: gcc-patches, java-patches
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
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: PATCH: PR libjava/32078: Update libtool in classpath
2007-05-29 10:48 ` Andrew Haley
@ 2007-05-29 13:10 ` Paolo Bonzini
0 siblings, 0 replies; 46+ messages in thread
From: Paolo Bonzini @ 2007-05-29 13:10 UTC (permalink / raw)
To: Andrew Haley
Cc: Andreas Schwab, H. J. Lu, gcc-patches, java-patches, Classpath Patches
> 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
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: PATCH: PR libjava/32078: Update libtool in classpath
2007-05-29 12:17 ` Matthias Klose
@ 2007-05-29 13:43 ` H. J. Lu
2007-05-29 13:44 ` Paolo Bonzini
0 siblings, 1 reply; 46+ messages in thread
From: H. J. Lu @ 2007-05-29 13:43 UTC (permalink / raw)
To: Matthias Klose; +Cc: gcc-patches, java-patches
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.
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: PATCH: PR libjava/32078: Update libtool in classpath
2007-05-29 13:43 ` H. J. Lu
@ 2007-05-29 13:44 ` Paolo Bonzini
2007-05-29 13:47 ` H. J. Lu
2007-05-29 16:32 ` Andreas Schwab
0 siblings, 2 replies; 46+ messages in thread
From: Paolo Bonzini @ 2007-05-29 13:44 UTC (permalink / raw)
To: H. J. Lu; +Cc: Matthias Klose, gcc-patches, java-patches
>>> 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
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: PATCH: PR libjava/32078: Update libtool in classpath
2007-05-29 13:44 ` Paolo Bonzini
@ 2007-05-29 13:47 ` H. J. Lu
2007-05-29 13:55 ` Paolo Bonzini
2007-05-29 16:32 ` Andreas Schwab
1 sibling, 1 reply; 46+ messages in thread
From: H. J. Lu @ 2007-05-29 13:47 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: Matthias Klose, gcc-patches, java-patches
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.
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: PATCH: PR libjava/32078: Update libtool in classpath
2007-05-29 13:47 ` H. J. Lu
@ 2007-05-29 13:55 ` Paolo Bonzini
2007-05-29 14:25 ` Andrew Haley
0 siblings, 1 reply; 46+ messages in thread
From: Paolo Bonzini @ 2007-05-29 13:55 UTC (permalink / raw)
To: H. J. Lu; +Cc: Matthias Klose, gcc-patches, java-patches, Andrew Haley
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
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: PATCH: PR libjava/32078: Update libtool in classpath
2007-05-29 13:55 ` Paolo Bonzini
@ 2007-05-29 14:25 ` Andrew Haley
2007-05-29 14:36 ` H. J. Lu
0 siblings, 1 reply; 46+ messages in thread
From: Andrew Haley @ 2007-05-29 14:25 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: H. J. Lu, Matthias Klose, gcc-patches, java-patches
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.
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: PATCH: PR libjava/32078: Update libtool in classpath
2007-05-29 14:25 ` Andrew Haley
@ 2007-05-29 14:36 ` H. J. Lu
2007-05-29 14:40 ` Andrew Haley
0 siblings, 1 reply; 46+ messages in thread
From: H. J. Lu @ 2007-05-29 14:36 UTC (permalink / raw)
To: Andrew Haley; +Cc: Paolo Bonzini, Matthias Klose, gcc-patches, java-patches
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.
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: PATCH: PR libjava/32078: Update libtool in classpath
2007-05-29 14:36 ` H. J. Lu
@ 2007-05-29 14:40 ` Andrew Haley
2007-05-29 14:41 ` H. J. Lu
0 siblings, 1 reply; 46+ messages in thread
From: Andrew Haley @ 2007-05-29 14:40 UTC (permalink / raw)
To: H. J. Lu; +Cc: Paolo Bonzini, Matthias Klose, gcc-patches, java-patches
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.
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: PATCH: PR libjava/32078: Update libtool in classpath
2007-05-29 14:40 ` Andrew Haley
@ 2007-05-29 14:41 ` H. J. Lu
2007-05-29 14:43 ` Andrew Haley
2007-05-29 14:46 ` Paolo Bonzini
0 siblings, 2 replies; 46+ messages in thread
From: H. J. Lu @ 2007-05-29 14:41 UTC (permalink / raw)
To: Andrew Haley; +Cc: Paolo Bonzini, Matthias Klose, gcc-patches, java-patches
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.
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: PATCH: PR libjava/32078: Update libtool in classpath
2007-05-29 14:41 ` H. J. Lu
@ 2007-05-29 14:43 ` Andrew Haley
2007-05-29 14:49 ` Andrew Haley
2007-05-29 14:46 ` Paolo Bonzini
1 sibling, 1 reply; 46+ messages in thread
From: Andrew Haley @ 2007-05-29 14:43 UTC (permalink / raw)
To: H. J. Lu; +Cc: Paolo Bonzini, Matthias Klose, gcc-patches, java-patches
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.
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: PATCH: PR libjava/32078: Update libtool in classpath
2007-05-29 14:41 ` H. J. Lu
2007-05-29 14:43 ` Andrew Haley
@ 2007-05-29 14:46 ` Paolo Bonzini
2007-05-29 14:54 ` Andrew Haley
2007-05-29 14:59 ` Paolo Bonzini
1 sibling, 2 replies; 46+ messages in thread
From: Paolo Bonzini @ 2007-05-29 14:46 UTC (permalink / raw)
To: H. J. Lu; +Cc: Andrew Haley, Matthias Klose, gcc-patches, java-patches
>> > > 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
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: PATCH: PR libjava/32078: Update libtool in classpath
2007-05-29 14:43 ` Andrew Haley
@ 2007-05-29 14:49 ` Andrew Haley
2007-05-29 15:09 ` Paolo Bonzini
0 siblings, 1 reply; 46+ messages in thread
From: Andrew Haley @ 2007-05-29 14:49 UTC (permalink / raw)
To: H. J. Lu, Paolo Bonzini, Matthias Klose, gcc-patches, java-patches
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.
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: PATCH: PR libjava/32078: Update libtool in classpath
2007-05-29 14:46 ` Paolo Bonzini
@ 2007-05-29 14:54 ` Andrew Haley
2007-05-29 14:59 ` Paolo Bonzini
1 sibling, 0 replies; 46+ messages in thread
From: Andrew Haley @ 2007-05-29 14:54 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: H. J. Lu, Matthias Klose, gcc-patches, java-patches
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.
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: PATCH: PR libjava/32078: Update libtool in classpath
2007-05-29 14:46 ` Paolo Bonzini
2007-05-29 14:54 ` Andrew Haley
@ 2007-05-29 14:59 ` Paolo Bonzini
1 sibling, 0 replies; 46+ messages in thread
From: Paolo Bonzini @ 2007-05-29 14:59 UTC (permalink / raw)
To: gcc-patches; +Cc: java-patches, gcc-patches
>> > > 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
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: PATCH: PR libjava/32078: Update libtool in classpath
2007-05-29 14:49 ` Andrew Haley
@ 2007-05-29 15:09 ` Paolo Bonzini
2007-05-29 15:19 ` H. J. Lu
0 siblings, 1 reply; 46+ messages in thread
From: Paolo Bonzini @ 2007-05-29 15:09 UTC (permalink / raw)
To: Andrew Haley
Cc: H. J. Lu, Matthias Klose, gcc-patches, java-patches, libtool-patches
> > 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
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: PATCH: PR libjava/32078: Update libtool in classpath
2007-05-29 15:19 ` H. J. Lu
@ 2007-05-29 15:19 ` Paolo Bonzini
2007-05-29 15:25 ` Andrew Haley
2007-05-29 15:26 ` H. J. Lu
0 siblings, 2 replies; 46+ messages in thread
From: Paolo Bonzini @ 2007-05-29 15:19 UTC (permalink / raw)
To: H. J. Lu
Cc: Andrew Haley, Matthias Klose, gcc-patches, java-patches, libtool-patches
>>>> 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
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: PATCH: PR libjava/32078: Update libtool in classpath
2007-05-29 15:09 ` Paolo Bonzini
@ 2007-05-29 15:19 ` H. J. Lu
2007-05-29 15:19 ` Paolo Bonzini
0 siblings, 1 reply; 46+ messages in thread
From: H. J. Lu @ 2007-05-29 15:19 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Andrew Haley, Matthias Klose, gcc-patches, java-patches, libtool-patches
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.
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: PATCH: PR libjava/32078: Update libtool in classpath
2007-05-29 15:19 ` Paolo Bonzini
@ 2007-05-29 15:25 ` Andrew Haley
2007-05-29 15:36 ` H. J. Lu
2007-05-29 15:26 ` H. J. Lu
1 sibling, 1 reply; 46+ messages in thread
From: Andrew Haley @ 2007-05-29 15:25 UTC (permalink / raw)
To: Paolo Bonzini
Cc: H. J. Lu, Matthias Klose, gcc-patches, java-patches, libtool-patches
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.
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: PATCH: PR libjava/32078: Update libtool in classpath
2007-05-29 15:19 ` Paolo Bonzini
2007-05-29 15:25 ` Andrew Haley
@ 2007-05-29 15:26 ` H. J. Lu
2007-05-29 15:44 ` Andrew Haley
1 sibling, 1 reply; 46+ messages in thread
From: H. J. Lu @ 2007-05-29 15:26 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Andrew Haley, Matthias Klose, gcc-patches, java-patches, libtool-patches
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.
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: PATCH: PR libjava/32078: Update libtool in classpath
2007-05-29 15:25 ` Andrew Haley
@ 2007-05-29 15:36 ` H. J. Lu
0 siblings, 0 replies; 46+ messages in thread
From: H. J. Lu @ 2007-05-29 15:36 UTC (permalink / raw)
To: Andrew Haley
Cc: Paolo Bonzini, Matthias Klose, gcc-patches, java-patches,
libtool-patches
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.
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: PATCH: PR libjava/32078: Update libtool in classpath
2007-05-29 15:26 ` H. J. Lu
@ 2007-05-29 15:44 ` Andrew Haley
2007-05-29 17:16 ` Maciej W. Rozycki
0 siblings, 1 reply; 46+ messages in thread
From: Andrew Haley @ 2007-05-29 15:44 UTC (permalink / raw)
To: H. J. Lu
Cc: Paolo Bonzini, Matthias Klose, gcc-patches, java-patches,
libtool-patches
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.
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: PATCH: PR libjava/32078: Update libtool in classpath
2007-05-29 13:44 ` Paolo Bonzini
2007-05-29 13:47 ` H. J. Lu
@ 2007-05-29 16:32 ` Andreas Schwab
2007-05-29 16:41 ` H. J. Lu
1 sibling, 1 reply; 46+ messages in thread
From: Andreas Schwab @ 2007-05-29 16:32 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: H. J. Lu, Matthias Klose, gcc-patches, java-patches
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."
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: PATCH: PR libjava/32078: Update libtool in classpath
2007-05-29 16:32 ` Andreas Schwab
@ 2007-05-29 16:41 ` H. J. Lu
2007-05-29 17:21 ` Andreas Schwab
0 siblings, 1 reply; 46+ messages in thread
From: H. J. Lu @ 2007-05-29 16:41 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Paolo Bonzini, Matthias Klose, gcc-patches, java-patches
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.
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: PATCH: PR libjava/32078: Update libtool in classpath
2007-05-29 15:44 ` Andrew Haley
@ 2007-05-29 17:16 ` Maciej W. Rozycki
0 siblings, 0 replies; 46+ messages in thread
From: Maciej W. Rozycki @ 2007-05-29 17:16 UTC (permalink / raw)
To: Andrew Haley
Cc: H. J. Lu, Paolo Bonzini, Matthias Klose, gcc-patches,
java-patches, libtool-patches
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
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: PATCH: PR libjava/32078: Update libtool in classpath
2007-05-29 16:41 ` H. J. Lu
@ 2007-05-29 17:21 ` Andreas Schwab
2007-05-29 17:36 ` H. J. Lu
0 siblings, 1 reply; 46+ messages in thread
From: Andreas Schwab @ 2007-05-29 17:21 UTC (permalink / raw)
To: H. J. Lu; +Cc: Paolo Bonzini, Matthias Klose, gcc-patches, java-patches
"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."
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: PATCH: PR libjava/32078: Update libtool in classpath
2007-05-29 17:21 ` Andreas Schwab
@ 2007-05-29 17:36 ` H. J. Lu
2007-05-29 17:54 ` Andreas Schwab
0 siblings, 1 reply; 46+ messages in thread
From: H. J. Lu @ 2007-05-29 17:36 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Paolo Bonzini, Matthias Klose, gcc-patches, java-patches
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.
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: PATCH: PR libjava/32078: Update libtool in classpath
2007-05-29 17:36 ` H. J. Lu
@ 2007-05-29 17:54 ` Andreas Schwab
2007-05-29 18:29 ` H. J. Lu
0 siblings, 1 reply; 46+ messages in thread
From: Andreas Schwab @ 2007-05-29 17:54 UTC (permalink / raw)
To: H. J. Lu; +Cc: Paolo Bonzini, Matthias Klose, gcc-patches, java-patches
"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."
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: PATCH: PR libjava/32078: Update libtool in classpath
2007-05-29 17:54 ` Andreas Schwab
@ 2007-05-29 18:29 ` H. J. Lu
2007-05-29 18:35 ` Tom Tromey
0 siblings, 1 reply; 46+ messages in thread
From: H. J. Lu @ 2007-05-29 18:29 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Paolo Bonzini, Matthias Klose, gcc-patches, java-patches
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.
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: PATCH: PR libjava/32078: Update libtool in classpath
2007-05-29 18:29 ` H. J. Lu
@ 2007-05-29 18:35 ` Tom Tromey
2007-05-29 23:14 ` H. J. Lu
0 siblings, 1 reply; 46+ messages in thread
From: Tom Tromey @ 2007-05-29 18:35 UTC (permalink / raw)
To: H. J. Lu
Cc: Andreas Schwab, Paolo Bonzini, Matthias Klose, gcc-patches, java-patches
>>>>> "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
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: PATCH: PR libjava/32078: Update libtool in classpath
2007-05-29 18:35 ` Tom Tromey
@ 2007-05-29 23:14 ` H. J. Lu
2007-05-30 8:22 ` Paolo Bonzini
2007-05-30 17:46 ` Tom Tromey
0 siblings, 2 replies; 46+ messages in thread
From: H. J. Lu @ 2007-05-29 23:14 UTC (permalink / raw)
To: Tom Tromey
Cc: Andreas Schwab, Paolo Bonzini, Matthias Klose, gcc-patches, java-patches
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
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: PATCH: PR libjava/32078: Update libtool in classpath
2007-05-29 23:14 ` H. J. Lu
@ 2007-05-30 8:22 ` Paolo Bonzini
2007-05-30 17:46 ` Tom Tromey
1 sibling, 0 replies; 46+ messages in thread
From: Paolo Bonzini @ 2007-05-30 8:22 UTC (permalink / raw)
To: H. J. Lu
Cc: Tom Tromey, Andreas Schwab, Matthias Klose, gcc-patches, java-patches
> 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
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: PATCH: PR libjava/32078: Update libtool in classpath
2007-05-29 23:14 ` H. J. Lu
2007-05-30 8:22 ` Paolo Bonzini
@ 2007-05-30 17:46 ` Tom Tromey
2007-05-30 18:03 ` H. J. Lu
1 sibling, 1 reply; 46+ messages in thread
From: Tom Tromey @ 2007-05-30 17:46 UTC (permalink / raw)
To: H. J. Lu
Cc: Andreas Schwab, Paolo Bonzini, Matthias Klose, gcc-patches, java-patches
>>>>> "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
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: PATCH: PR libjava/32078: Update libtool in classpath
2007-05-30 17:46 ` Tom Tromey
@ 2007-05-30 18:03 ` H. J. Lu
2007-05-30 18:19 ` Tom Tromey
2007-05-30 20:01 ` Peter O'Gorman
0 siblings, 2 replies; 46+ messages in thread
From: H. J. Lu @ 2007-05-30 18:03 UTC (permalink / raw)
To: Tom Tromey
Cc: Andreas Schwab, Paolo Bonzini, Matthias Klose, gcc-patches, java-patches
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.
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: PATCH: PR libjava/32078: Update libtool in classpath
2007-05-30 18:03 ` H. J. Lu
@ 2007-05-30 18:19 ` Tom Tromey
2007-05-31 9:37 ` Paolo Bonzini
2007-05-30 20:01 ` Peter O'Gorman
1 sibling, 1 reply; 46+ messages in thread
From: Tom Tromey @ 2007-05-30 18:19 UTC (permalink / raw)
To: H. J. Lu
Cc: Andreas Schwab, Paolo Bonzini, Matthias Klose, gcc-patches, java-patches
>>>>> "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
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: PATCH: PR libjava/32078: Update libtool in classpath
2007-05-30 18:03 ` H. J. Lu
2007-05-30 18:19 ` Tom Tromey
@ 2007-05-30 20:01 ` Peter O'Gorman
2007-05-30 22:37 ` H. J. Lu
1 sibling, 1 reply; 46+ messages in thread
From: Peter O'Gorman @ 2007-05-30 20:01 UTC (permalink / raw)
To: H. J. Lu
Cc: Tom Tromey, Andreas Schwab, Paolo Bonzini, Matthias Klose,
gcc-patches, java-patches
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
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: PATCH: PR libjava/32078: Update libtool in classpath
2007-05-30 20:01 ` Peter O'Gorman
@ 2007-05-30 22:37 ` H. J. Lu
0 siblings, 0 replies; 46+ messages in thread
From: H. J. Lu @ 2007-05-30 22:37 UTC (permalink / raw)
To: Peter O'Gorman
Cc: Tom Tromey, Andreas Schwab, Paolo Bonzini, Matthias Klose,
gcc-patches, java-patches
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.
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: PATCH: PR libjava/32078: Update libtool in classpath
2007-05-30 18:19 ` Tom Tromey
@ 2007-05-31 9:37 ` Paolo Bonzini
2007-05-31 15:26 ` Tom Tromey
0 siblings, 1 reply; 46+ messages in thread
From: Paolo Bonzini @ 2007-05-31 9:37 UTC (permalink / raw)
To: tromey
Cc: H. J. Lu, Andreas Schwab, Matthias Klose, gcc-patches, java-patches
[-- 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
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: PATCH: PR libjava/32078: Update libtool in classpath
2007-05-31 9:37 ` Paolo Bonzini
@ 2007-05-31 15:26 ` Tom Tromey
0 siblings, 0 replies; 46+ messages in thread
From: Tom Tromey @ 2007-05-31 15:26 UTC (permalink / raw)
To: Paolo Bonzini
Cc: H. J. Lu, Andreas Schwab, Matthias Klose, gcc-patches, java-patches
>>>>> "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
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: PATCH: PR libjava/32078: Update libtool in classpath
2007-05-29 17:05 Charles Wilson
@ 2007-05-29 17:07 ` Charles Wilson
0 siblings, 0 replies; 46+ messages in thread
From: Charles Wilson @ 2007-05-29 17:07 UTC (permalink / raw)
To: gcc-patches; +Cc: bonzini, hjl, java-patches
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
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: PATCH: PR libjava/32078: Update libtool in classpath
@ 2007-05-29 17:05 Charles Wilson
2007-05-29 17:07 ` Charles Wilson
0 siblings, 1 reply; 46+ messages in thread
From: Charles Wilson @ 2007-05-29 17:05 UTC (permalink / raw)
To: gcc-patches; +Cc: bonzini, hjl, oko, java-patches
> > 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
^ permalink raw reply [flat|nested] 46+ messages in thread
end of thread, other threads:[~2007-05-31 14:48 UTC | newest]
Thread overview: 46+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-05-27 18:25 PATCH: PR libjava/32078: Update libtool in classpath H. J. Lu
2007-05-27 18:53 ` H. J. Lu
[not found] ` <20070527182317.GA21785@lucon.org>
2007-05-29 10:25 ` Andrew Haley
2007-05-29 10:46 ` Andreas Schwab
2007-05-29 10:48 ` Andrew Haley
2007-05-29 13:10 ` Paolo Bonzini
2007-05-29 12:17 ` Matthias Klose
2007-05-29 13:43 ` H. J. Lu
2007-05-29 13:44 ` Paolo Bonzini
2007-05-29 13:47 ` H. J. Lu
2007-05-29 13:55 ` Paolo Bonzini
2007-05-29 14:25 ` Andrew Haley
2007-05-29 14:36 ` H. J. Lu
2007-05-29 14:40 ` Andrew Haley
2007-05-29 14:41 ` H. J. Lu
2007-05-29 14:43 ` Andrew Haley
2007-05-29 14:49 ` Andrew Haley
2007-05-29 15:09 ` Paolo Bonzini
2007-05-29 15:19 ` H. J. Lu
2007-05-29 15:19 ` Paolo Bonzini
2007-05-29 15:25 ` Andrew Haley
2007-05-29 15:36 ` H. J. Lu
2007-05-29 15:26 ` H. J. Lu
2007-05-29 15:44 ` Andrew Haley
2007-05-29 17:16 ` Maciej W. Rozycki
2007-05-29 14:46 ` Paolo Bonzini
2007-05-29 14:54 ` Andrew Haley
2007-05-29 14:59 ` Paolo Bonzini
2007-05-29 16:32 ` Andreas Schwab
2007-05-29 16:41 ` H. J. Lu
2007-05-29 17:21 ` Andreas Schwab
2007-05-29 17:36 ` H. J. Lu
2007-05-29 17:54 ` Andreas Schwab
2007-05-29 18:29 ` H. J. Lu
2007-05-29 18:35 ` Tom Tromey
2007-05-29 23:14 ` H. J. Lu
2007-05-30 8:22 ` Paolo Bonzini
2007-05-30 17:46 ` Tom Tromey
2007-05-30 18:03 ` H. J. Lu
2007-05-30 18:19 ` Tom Tromey
2007-05-31 9:37 ` Paolo Bonzini
2007-05-31 15:26 ` Tom Tromey
2007-05-30 20:01 ` Peter O'Gorman
2007-05-30 22:37 ` H. J. Lu
2007-05-29 17:05 Charles Wilson
2007-05-29 17:07 ` Charles Wilson
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).