* 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
[parent not found: <20070527182317.GA21785@lucon.org>]
* 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 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 [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 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: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: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: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 ` 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: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: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: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: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 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 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: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 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 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: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-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-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
* 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
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).