PATCH: PR libjava/32098: New libtool doesn't support libjava

PATCH: PR libjava/32098: New libtool doesn't support libjava

[Charles Wilson]

H.J. Lu wrote:
> New libtool calls gcj to test gcj features. However, gcj isn't
> fully functional when building libjava since ecj1 isn't available.
> As the result, libtool created for libjava isn't really correct.
> This patch uses gcc to test gcj features like PIC and "-c -o".

Is there any way to achieve this result without forking libtool? [1,2,3]
Perhaps by using some of the techniques in libstdc++'s acinclude?
http://gcc.gnu.org/viewcvs/trunk/libstdc%2B%2B-v3/acinclude.m4?revision=124896&view=markup

[1] especially as Steve just got finished resyncing it with the official
libtool sources

[2] changes in toplevel .m4 files require regenerating every Makefile.in
and configure script in all of gcc/ and src/ trees

[3] finally, quoting myself from
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01654.html
> However, wasn't the point of using ToT libtool: to _avoid_ haring off
> with quick-n-dirty [*] local patches -- in effect, forking libtool?
> Instead of fixing gcc's local copy, shouldn't this fix -- or a better
> one -- instead be submitted to libtool, and then gcc can resync?

--
Chuck

Re: PATCH: PR libjava/32098: New libtool doesn't support libjava

[H. J. Lu]

On Sun, May 27, 2007 at 04:20:02PM -0400, Charles Wilson wrote:
> H.J. Lu wrote:
> > New libtool calls gcj to test gcj features. However, gcj isn't
> > fully functional when building libjava since ecj1 isn't available.
> > As the result, libtool created for libjava isn't really correct.
> > This patch uses gcc to test gcj features like PIC and "-c -o".
> 
> Is there any way to achieve this result without forking libtool? [1,2,3]

That is the best I can find.

> Perhaps by using some of the techniques in libstdc++'s acinclude?
> http://gcc.gnu.org/viewcvs/trunk/libstdc%2B%2B-v3/acinclude.m4?revision=124896&view=markup
> 

Please be more specific. That is a huge file.


H.J.

Re: PATCH: PR libjava/32098: New libtool doesn't support libjava

[Paolo Bonzini]

H. J. Lu wrote:
> On Sun, May 27, 2007 at 04:20:02PM -0400, Charles Wilson wrote:
>> H.J. Lu wrote:
>>> New libtool calls gcj to test gcj features. However, gcj isn't
>>> fully functional when building libjava since ecj1 isn't available.
>>> As the result, libtool created for libjava isn't really correct.
>>> This patch uses gcc to test gcj features like PIC and "-c -o".
>> Is there any way to achieve this result without forking libtool? [1,2,3]
> 
> That is the best I can find.

No, that's wrong.  You can try changing libtool.m4 to run tests on 
.class files instead; compile them with an old GCJ, and include the 
bytecode in libtool.m4, using tr or awk to turn ASCII strings into bytecode.

This is a kind of patch that, I think, will be acceptable upstream (it 
will be accepted as an interim measure in the GCC libtool, but it will 
have to be included in libtool itself too).

Paolo

Re: PATCH: PR libjava/32098: New libtool doesn't support libjava

[H. J. Lu]

On Sun, May 27, 2007 at 11:15:20PM +0200, Paolo Bonzini wrote:
> H. J. Lu wrote:
> >On Sun, May 27, 2007 at 04:20:02PM -0400, Charles Wilson wrote:
> >>H.J. Lu wrote:
> >>>New libtool calls gcj to test gcj features. However, gcj isn't
> >>>fully functional when building libjava since ecj1 isn't available.
> >>>As the result, libtool created for libjava isn't really correct.
> >>>This patch uses gcc to test gcj features like PIC and "-c -o".
> >>Is there any way to achieve this result without forking libtool? [1,2,3]
> >
> >That is the best I can find.
> 
> No, that's wrong.  You can try changing libtool.m4 to run tests on 
> .class files instead; compile them with an old GCJ, and include the 
> bytecode in libtool.m4, using tr or awk to turn ASCII strings into bytecode.
> 

That is the best I can find. I don't know anything about .classs file
nor java bytecode.


H.J.

Re: PATCH: PR libjava/32098: New libtool doesn't support libjava

[libtool]

On Sun, 27 May 2007 13:52:06 -0700, "H. J. Lu" <hjl@lucon.org> said:
> On Sun, May 27, 2007 at 04:20:02PM -0400, Charles Wilson wrote:
> > Perhaps by using some of the techniques in libstdc++'s acinclude?
> > http://gcc.gnu.org/viewcvs/trunk/libstdc%2B%2B-v3/acinclude.m4?revision=124896&view=markup
> > 
> 
> Please be more specific. That is a huge file.

I meant inserting something like the bit below into libjava's
acinclude.m4, only for GCJ instead of CXX.  It was just an offhand idea;
I know very little about libjava's configury needs.

---------------------------------------------------
  # We're almost certainly being configured before anything else which
  uses
  # C++, so all of our AC_PROG_* discoveries will be cached.  It's vital
  that
  # we not cache the value of CXX that we "discover" here, because it's
  set
  # to something unique for us and libjava.  Other target libraries need
  to
  # find CXX for themselves.  We yank the rug out from under the normal
  AC_*
  # process by sneakily renaming the cache variable.  This also lets us
  debug
  # the value of "our" CXX in postmortems.
  #
  # We must also force CXX to /not/ be a precious variable, otherwise
  the
  # wrong (non-multilib-adjusted) value will be used in multilibs.  This
  # little trick also affects CPPFLAGS, CXXFLAGS, and LDFLAGS.  And as a
  side
  # effect, CXXFLAGS is no longer automagically subst'd, so we have to
  do
  # that ourselves.  Un-preciousing AC_PROG_CC also affects CC and
  CFLAGS.
  #
  # -fno-builtin must be present here so that a non-conflicting form of
  # std::exit can be guessed by AC_PROG_CXX, and used in later tests.

  m4_define([ac_cv_prog_CXX],[glibcxx_cv_prog_CXX])
  m4_rename([_AC_ARG_VAR_PRECIOUS],[glibcxx_PRECIOUS])
  m4_define([_AC_ARG_VAR_PRECIOUS],[])
  save_CXXFLAGS="$CXXFLAGS"
  CXXFLAGS="$CXXFLAGS -fno-builtin"
  AC_PROG_CC
  AC_PROG_CXX
  CXXFLAGS="$save_CXXFLAGS"
  m4_rename([glibcxx_PRECIOUS],[_AC_ARG_VAR_PRECIOUS])
  AC_SUBST(CFLAGS)
  AC_SUBST(CXXFLAGS)
---------------------------------------------------


--
Chuck

Re: PATCH: PR libjava/32098: New libtool doesn't support libjava

[H. J. Lu]

On Sun, May 27, 2007 at 08:12:21PM -0400, libtool@cwilson.fastmail.fm wrote:
> 
> On Sun, 27 May 2007 13:52:06 -0700, "H. J. Lu" <hjl@lucon.org> said:
> > On Sun, May 27, 2007 at 04:20:02PM -0400, Charles Wilson wrote:
> > > Perhaps by using some of the techniques in libstdc++'s acinclude?
> > > http://gcc.gnu.org/viewcvs/trunk/libstdc%2B%2B-v3/acinclude.m4?revision=124896&view=markup
> > > 
> > 
> > Please be more specific. That is a huge file.
> 
> I meant inserting something like the bit below into libjava's
> acinclude.m4, only for GCJ instead of CXX.  It was just an offhand idea;
> I know very little about libjava's configury needs.
> 
> 
>   m4_define([ac_cv_prog_CXX],[glibcxx_cv_prog_CXX])
>   m4_rename([_AC_ARG_VAR_PRECIOUS],[glibcxx_PRECIOUS])
>   m4_define([_AC_ARG_VAR_PRECIOUS],[])
>   save_CXXFLAGS="$CXXFLAGS"
>   CXXFLAGS="$CXXFLAGS -fno-builtin"
>   AC_PROG_CC
>   AC_PROG_CXX
>   CXXFLAGS="$save_CXXFLAGS"
>   m4_rename([glibcxx_PRECIOUS],[_AC_ARG_VAR_PRECIOUS])
>   AC_SUBST(CFLAGS)
>   AC_SUBST(CXXFLAGS)

The same thing is in libjava/configure.ac. It is used to suppress:

ac_env_CXX_set=${CXX+set}
ac_env_CXX_value=$CXX
ac_cv_env_CXX_set=${CXX+set}
ac_cv_env_CXX_value=$CXX
ac_env_CXXFLAGS_set=${CXXFLAGS+set}
ac_env_CXXFLAGS_value=$CXXFLAGS
ac_cv_env_CXXFLAGS_set=${CXXFLAGS+set}
ac_cv_env_CXXFLAGS_value=$CXXFLAGS

which is needed for:

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

Unfortunately, it nolonger works with the new libtool. We are getting
them in libjava. In fact, they are also in libstdc++/configure. That
means the kludge in libstdc++ doesn't work either.  I am testing a
kludge for PR 32078.


H.J.

Re: PATCH: PR libjava/32098: New libtool doesn't support libjava

[Paolo Bonzini]

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


>> No, that's wrong.  You can try changing libtool.m4 to run tests on 
>> .class files instead; compile them with an old GCJ, and include the 
>> bytecode in libtool.m4, using tr or awk to turn ASCII strings into bytecode.
>>
> 
> That is the best I can find. I don't know anything about .classs file
> nor java bytecode.

So the attached patch (untested because the problem does not reproduce 
on my machine) should give you an idea of what I meant.  Please test it 
and/or fix it.

Libtool maintainers, would you accept a patch like this one?  The 
problem is that under some configurations, GCC 4.3 cannot compile Java 
source code until its build has finished.

Paolo

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

2007-05-27  Paolo Bonzini  <bonzini@gnu.org>

	* libtool.m4 (_LT_LANG_GCJ_CONFIG): Run tests on .class files.

Index: libtool.m4
===================================================================
--- libtool.m4	(revision 125123)
+++ libtool.m4	(working copy)
@@ -6737,18 +6737,54 @@ m4_defun([_LT_LANG_GCJ_CONFIG],
 [AC_REQUIRE([LT_PROG_GCJ])dnl
 AC_LANG_SAVE
 
-# Source file extension for Java test sources.
-ac_ext=java
+# Source file extension for Java test sources.  Actually, we use a list
+# of input files so that we can prepare binary .class files and keep
+# lt_simple_compile_test_code/lt_simple_link_test_code in ASCII.
+ac_ext=list
 
 # 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="class foo {}"
+# "class conftest_compile {}"
+# Turn it into hex using "od -x foo.class | sed s/^.......// | tr -d ' '"
+lt_simple_compile_test_code='conftest_compile.class'
+awk 'BEGIN { h = "0123456789abcdef" }
+  {
+    for (i = 1; i <= length; i+=2)
+      printf "%c", 16*index(h, substr($0, i, 1))+index(h, substr($0, i+1, 1))-17
+  }' > conftest_compile.class << EOF
+cafebabe00000031000d0a0003000a07000b07000c0100063c696e69743e0100
+03282956010004436f646501000f4c696e654e756d6265725461626c6501000a
+536f7572636546696c65010015636f6e66746573745f636f6d70696c652e6a61
+76610c00040005010010636f6e66746573745f636f6d70696c650100106a6176
+612f6c616e672f4f626a65637400200002000300000000000100000004000500
+0100060000001d00010001000000052ab70001b1000000010007000000060001
+0000000100010008000000020009
+EOF
 
 # Code to be used in simple link tests
-lt_simple_link_test_code='public class conftest { public static void main(String[[]] argv) {}; }'
+# "public class conftest_link { public static void main(String[[]] argv) {}; }"
+lt_simple_link_test_code='conftest_link.class'
+awk 'BEGIN { h = "0123456789abcdef" }
+  {
+    for (i = 1; i <= length; i+=2)
+      printf "%c", 16*index(h, substr($0, i, 1))+index(h, substr($0, i+1, 1))-17
+  }' > conftest_link.class << EOF
+cafebabe00000031000f0a0003000c07000d07000e0100063c696e69743e0100
+03282956010004436f646501000f4c696e654e756d6265725461626c65010004
+6d61696e010016285b4c6a6176612f6c616e672f537472696e673b295601000a
+536f7572636546696c65010012636f6e66746573745f6c696e6b2e6a6176610c
+0004000501000d636f6e66746573745f6c696e6b0100106a6176612f6c616e67
+2f4f626a65637400210002000300000000000200010004000500010006000000
+1d00010001000000052ab70001b1000000010007000000060001000000010009
+0008000900010006000000190000000100000001b10000000100070000000600
+01000000010001000a00000002000b00
+EOF
+
+lt_save_ac_compile="$ac_compile"
+ac_compile='$CC -c $CFLAGS $CPPFLAGS @conftest.$ac_ext >&5'
 
 # ltmain only uses $CC for tagged configurations so make sure $CC is set.
 _LT_TAG_COMPILER
@@ -6786,6 +6822,7 @@ if test -n "$compiler"; then
 fi
 
 AC_LANG_RESTORE
+ac_compile="$lt_save_ac_compile"
 CC="$lt_save_CC"
 ])# _LT_LANG_GCJ_CONFIG
 

Re: PATCH: PR libjava/32098: New libtool doesn't support libjava

[Peter O'Gorman]

On May 28, 2007, at 2:21 AM, Paolo Bonzini wrote:

>
>>> No, that's wrong.  You can try changing libtool.m4 to run tests  
>>> on .class files instead; compile them with an old GCJ, and  
>>> include the bytecode in libtool.m4, using tr or awk to turn ASCII  
>>> strings into bytecode.
>>>
>> That is the best I can find. I don't know anything about .classs file
>> nor java bytecode.
>
> So the attached patch (untested because the problem does not  
> reproduce on my machine) should give you an idea of what I meant.   
> Please test it and/or fix it.
>
> Libtool maintainers, would you accept a patch like this one?  The  
> problem is that under some configurations, GCC 4.3 cannot compile  
> Java source code until its build has finished.
>
> Paolo
> 2007-05-27  Paolo Bonzini  <bonzini@gnu.org>
>
> 	* libtool.m4 (_LT_LANG_GCJ_CONFIG): Run tests on .class files.
>
> Index: libtool.m4
> ===================================================================
> --- libtool.m4	(revision 125123)
> +++ libtool.m4	(working copy)
> @@ -6737,18 +6737,54 @@ m4_defun([_LT_LANG_GCJ_CONFIG],
>  [AC_REQUIRE([LT_PROG_GCJ])dnl
>  AC_LANG_SAVE
>
> -# Source file extension for Java test sources.
> -ac_ext=java
> +# Source file extension for Java test sources.  Actually, we use a  
> list
> +# of input files so that we can prepare binary .class files and keep
> +# lt_simple_compile_test_code/lt_simple_link_test_code in ASCII.
> +ac_ext=list
>
>  # 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="class foo {}"
> +# "class conftest_compile {}"
> +# Turn it into hex using "od -x foo.class | sed s/^.......// | tr - 
> d ' '"
> +lt_simple_compile_test_code='conftest_compile.class'
> +awk 'BEGIN { h = "0123456789abcdef" }
> +  {
> +    for (i = 1; i <= length; i+=2)
> +      printf "%c", 16*index(h, substr($0, i, 1))+index(h, substr 
> ($0, i+1, 1))-17
> +  }' > conftest_compile.class << EOF
> +cafebabe00000031000d0a0003000a07000b07000c0100063c696e69743e0100
> +03282956010004436f646501000f4c696e654e756d6265725461626c6501000a
> +536f7572636546696c65010015636f6e66746573745f636f6d70696c652e6a61
> +76610c00040005010010636f6e66746573745f636f6d70696c650100106a6176
> +612f6c616e672f4f626a65637400200002000300000000000100000004000500
> +0100060000001d00010001000000052ab70001b1000000010007000000060001
> +0000000100010008000000020009
> +EOF

As I understand the theory (compile .class files instead of .java  
files) this is fine with me. However, being curious about the  
portability of the awk expression, I tried it on solaris, there with  
both awk and nawk, printf "%c",0; prints nothing at all, so all those  
00 above do not end up in the output. Needs another method to convert  
text to binary.

% od -x < conftest_compile.class
0000000 cafe babe 310d 0a03 0a07 0b07 0c01 063c
0000020 696e 6974 3e01 0328 2956 0104 436f 6465
0000040 010f 4c69 6e65 4e75 6d62 6572 5461 626c
0000060 6501 0a53 6f75 7263 6546 696c 6501 1563
0000100 6f6e 6674 6573 745f 636f 6d70 696c 652e
0000120 6a61 7661 0c04 0501 1063 6f6e 6674 6573
0000140 745f 636f 6d70 696c 6501 106a 6176 612f
0000160 6c61 6e67 2f4f 626a 6563 7420 0203 0104
0000200 0501 061d 0101 052a b701 b101 0706 0101
0000220 0108 0209


Thanks,
Peter
--
Peter O'Gorman
http://pogma.com

Re: PATCH: PR libjava/32098: New libtool doesn't support libjava

[Paolo Bonzini]

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

> As I understand the theory (compile .class files instead of .java files) 
> this is fine with me. However, being curious about the portability of 
> the awk expression, I tried it on solaris, there with both awk and nawk, 
> printf "%c",0; prints nothing at all, so all those 00 above do not end 
> up in the output. Needs another method to convert text to binary.

We can emit them as FF, and then use "tr" to convert them to NULs.  This 
ought to work.

Paolo

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

2007-05-27  Paolo Bonzini  <bonzini@gnu.org>

	* libtool.m4 (_LT_LANG_GCJ_CONFIG): Run tests on .class files.

Index: libtool.m4
===================================================================
--- libtool.m4	(revision 125123)
+++ libtool.m4	(working copy)
@@ -6737,18 +6737,55 @@ m4_defun([_LT_LANG_GCJ_CONFIG],
 [AC_REQUIRE([LT_PROG_GCJ])dnl
 AC_LANG_SAVE
 
-# Source file extension for Java test sources.
-ac_ext=java
+# Source file extension for Java test sources.  Actually, we use a list
+# of input files so that we can prepare binary .class files and keep
+# lt_simple_compile_test_code/lt_simple_link_test_code in ASCII.
+ac_ext=list
 
 # 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="class foo {}"
+# "class conftest_compile {}"
+# Eliminate NULs (for portability), and turn it into hex using
+#       tr \\000 \\377 < foo.class | od -x | sed s/^.......// | tr -d ' '
+lt_simple_compile_test_code='conftest_compile.class'
+awk 'BEGIN { h = "0123456789abcdef" }
+  {
+    for (i = 1; i <= length; i+=2)
+      printf "%c", 16*index(h, substr($0, i, 1))+index(h, substr($0, i+1, 1))-17
+  }' | tr \\377 \\000 > conftest_compile.class << EOF
+cafebabeffffff31ff0d0aff03ff0a07ff0b07ff0c01ff063c696e69743e01ff
+0328295601ff04436f646501ff0f4c696e654e756d6265725461626c6501ff0a
+536f7572636546696c6501ff15636f6e66746573745f636f6d70696c652e6a61
+76610cff04ff0501ff10636f6e66746573745f636f6d70696c6501ff106a6176
+612f6c616e672f4f626a656374ff20ff02ff03ffffffffff01ffffff04ff05ff
+01ff06ffffff1dff01ff01ffffff052ab7ff01b1ffffff01ff07ffffff06ff01
+ffffff01ff01ff08ffffff02ff09
+EOF
 
 # Code to be used in simple link tests
-lt_simple_link_test_code='public class conftest { public static void main(String[[]] argv) {}; }'
+# "public class conftest_link { public static void main(String[[]] argv) {}; }"
+lt_simple_link_test_code='conftest_link.class'
+awk 'BEGIN { h = "0123456789abcdef" }
+  {
+    for (i = 1; i <= length; i+=2)
+      printf "%c", 16*index(h, substr($0, i, 1))+index(h, substr($0, i+1, 1))-17
+  }' | tr \\377 \\000 > conftest_link.class << EOF
+cafebabeffffff31ff0f0aff03ff0c07ff0d07ff0e01ff063c696e69743e01ff
+0328295601ff04436f646501ff0f4c696e654e756d6265725461626c6501ff04
+6d61696e01ff16285b4c6a6176612f6c616e672f537472696e673b295601ff0a
+536f7572636546696c6501ff12636f6e66746573745f6c696e6b2e6a6176610c
+ff04ff0501ff0d636f6e66746573745f6c696e6b01ff106a6176612f6c616e67
+2f4f626a656374ff21ff02ff03ffffffffff02ff01ff04ff05ff01ff06ffffff
+1dff01ff01ffffff052ab7ff01b1ffffff01ff07ffffff06ff01ffffff01ff09
+ff08ff09ff01ff06ffffff19ffffff01ffffff01b1ffffff01ff07ffffff06ff
+01ffffff01ff01ff0affffff02ff0bff
+EOF
+
+lt_save_ac_compile="$ac_compile"
+ac_compile='$CC -c $CFLAGS $CPPFLAGS @conftest.$ac_ext >&5'
 
 # ltmain only uses $CC for tagged configurations so make sure $CC is set.
 _LT_TAG_COMPILER
@@ -6786,6 +6823,7 @@ if test -n "$compiler"; then
 fi
 
 AC_LANG_RESTORE
+ac_compile="$lt_save_ac_compile"
 CC="$lt_save_CC"
 ])# _LT_LANG_GCJ_CONFIG
 

Re: PATCH: PR libjava/32098: New libtool doesn't support libjava

[Paolo Bonzini]

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

> As I understand the theory (compile .class files instead of .java files) 
> this is fine with me. However, being curious about the portability of 
> the awk expression, I tried it on solaris, there with both awk and nawk, 
> printf "%c",0; prints nothing at all, so all those 00 above do not end 
> up in the output. Needs another method to convert text to binary.

We can emit them as FF, and then use "tr" to convert them to NULs.  This 
ought to work.

Paolo

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

2007-05-27  Paolo Bonzini  <bonzini@gnu.org>

	* libtool.m4 (_LT_LANG_GCJ_CONFIG): Run tests on .class files.

Index: libtool.m4
===================================================================
--- libtool.m4	(revision 125123)
+++ libtool.m4	(working copy)
@@ -6737,18 +6737,55 @@ m4_defun([_LT_LANG_GCJ_CONFIG],
 [AC_REQUIRE([LT_PROG_GCJ])dnl
 AC_LANG_SAVE
 
-# Source file extension for Java test sources.
-ac_ext=java
+# Source file extension for Java test sources.  Actually, we use a list
+# of input files so that we can prepare binary .class files and keep
+# lt_simple_compile_test_code/lt_simple_link_test_code in ASCII.
+ac_ext=list
 
 # 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="class foo {}"
+# "class conftest_compile {}"
+# Eliminate NULs (for portability), and turn it into hex using
+#       tr \\000 \\377 < foo.class | od -x | sed s/^.......// | tr -d ' '
+lt_simple_compile_test_code='conftest_compile.class'
+awk 'BEGIN { h = "0123456789abcdef" }
+  {
+    for (i = 1; i <= length; i+=2)
+      printf "%c", 16*index(h, substr($0, i, 1))+index(h, substr($0, i+1, 1))-17
+  }' | tr \\377 \\000 > conftest_compile.class << EOF
+cafebabeffffff31ff0d0aff03ff0a07ff0b07ff0c01ff063c696e69743e01ff
+0328295601ff04436f646501ff0f4c696e654e756d6265725461626c6501ff0a
+536f7572636546696c6501ff15636f6e66746573745f636f6d70696c652e6a61
+76610cff04ff0501ff10636f6e66746573745f636f6d70696c6501ff106a6176
+612f6c616e672f4f626a656374ff20ff02ff03ffffffffff01ffffff04ff05ff
+01ff06ffffff1dff01ff01ffffff052ab7ff01b1ffffff01ff07ffffff06ff01
+ffffff01ff01ff08ffffff02ff09
+EOF
 
 # Code to be used in simple link tests
-lt_simple_link_test_code='public class conftest { public static void main(String[[]] argv) {}; }'
+# "public class conftest_link { public static void main(String[[]] argv) {}; }"
+lt_simple_link_test_code='conftest_link.class'
+awk 'BEGIN { h = "0123456789abcdef" }
+  {
+    for (i = 1; i <= length; i+=2)
+      printf "%c", 16*index(h, substr($0, i, 1))+index(h, substr($0, i+1, 1))-17
+  }' | tr \\377 \\000 > conftest_link.class << EOF
+cafebabeffffff31ff0f0aff03ff0c07ff0d07ff0e01ff063c696e69743e01ff
+0328295601ff04436f646501ff0f4c696e654e756d6265725461626c6501ff04
+6d61696e01ff16285b4c6a6176612f6c616e672f537472696e673b295601ff0a
+536f7572636546696c6501ff12636f6e66746573745f6c696e6b2e6a6176610c
+ff04ff0501ff0d636f6e66746573745f6c696e6b01ff106a6176612f6c616e67
+2f4f626a656374ff21ff02ff03ffffffffff02ff01ff04ff05ff01ff06ffffff
+1dff01ff01ffffff052ab7ff01b1ffffff01ff07ffffff06ff01ffffff01ff09
+ff08ff09ff01ff06ffffff19ffffff01ffffff01b1ffffff01ff07ffffff06ff
+01ffffff01ff01ff0affffff02ff0bff
+EOF
+
+lt_save_ac_compile="$ac_compile"
+ac_compile='$CC -c $CFLAGS $CPPFLAGS @conftest.$ac_ext >&5'
 
 # ltmain only uses $CC for tagged configurations so make sure $CC is set.
 _LT_TAG_COMPILER
@@ -6786,6 +6823,7 @@ if test -n "$compiler"; then
 fi
 
 AC_LANG_RESTORE
+ac_compile="$lt_save_ac_compile"
 CC="$lt_save_CC"
 ])# _LT_LANG_GCJ_CONFIG
 

Re: PATCH: PR libjava/32098: New libtool doesn't support libjava

[H. J. Lu]

On Mon, May 28, 2007 at 11:53:50AM +0200, Paolo Bonzini wrote:
> >As I understand the theory (compile .class files instead of .java files) 
> >this is fine with me. However, being curious about the portability of 
> >the awk expression, I tried it on solaris, there with both awk and nawk, 
> >printf "%c",0; prints nothing at all, so all those 00 above do not end 
> >up in the output. Needs another method to convert text to binary.
> 
> We can emit them as FF, and then use "tr" to convert them to NULs.  This 
> ought to work.
> 

It dosn't work. I need to at least regeneate configure in libjava.
I got

bash-3.1$ cd libjava
bash-3.1$ autoconf
/usr/bin/m4:configure.ac:450: ERROR: recursion limit of 1024 exceeded, use -L<N> to change it
autom4te: /usr/bin/m4 failed with exit status: 1
bash-3.1$


H.J.

Re: PATCH: PR libjava/32098: New libtool doesn't support libjava

[Andreas Schwab]

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

> bash-3.1$ cd libjava
> bash-3.1$ autoconf
> /usr/bin/m4:configure.ac:450: ERROR: recursion limit of 1024 exceeded, use -L<N> to change it
> autom4te: /usr/bin/m4 failed with exit status: 1

Make sure that aclocal.m4 is correctly regenerated, using the right
version of ltdl.m4 (which is missing from toplevel).

Andreas.

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

Re: PATCH: PR libjava/32098: New libtool doesn't support libjava

[Jack Howarth]

HJ,
   Remember that Geoff's multilib fixes are in multi.m4
so that you need to use that file. When I regenerated
aclocal.m4, configure and Makefile.in for r120870, I
used.

cd libjava
aclocal  -I . -I .. -I ../config
autoconf  -I . -I .. -I ../config
automake -a
cd classpath
aclocal -I m4 -I ../.. -I ../../config
autoconf -I m4 -I ../.. -I ../../config
automake -a
cd ../libltdl
aclocal  -I ../.. -I ../../config
autoconf  -I ../.. -I ../../config
automake -a

Does that work better for you?
              Jack

On Mon, May 28, 2007 at 06:50:56AM -0700, H. J. Lu wrote:
> 
> It dosn't work. I need to at least regeneate configure in libjava.
> I got
> 
> bash-3.1$ cd libjava
> bash-3.1$ autoconf
> /usr/bin/m4:configure.ac:450: ERROR: recursion limit of 1024 exceeded, use -L<N> to change it
> autom4te: /usr/bin/m4 failed with exit status: 1
> bash-3.1$
> 
> 
> H.J.

Re: PATCH: PR libjava/32098: New libtool doesn't support libjava

[H. J. Lu]

On Mon, May 28, 2007 at 03:58:29PM +0200, Andreas Schwab wrote:
> "H. J. Lu" <hjl@lucon.org> writes:
> 
> > bash-3.1$ cd libjava
> > bash-3.1$ autoconf
> > /usr/bin/m4:configure.ac:450: ERROR: recursion limit of 1024 exceeded, use -L<N> to change it
> > autom4te: /usr/bin/m4 failed with exit status: 1
> 
> Make sure that aclocal.m4 is correctly regenerated, using the right
> version of ltdl.m4 (which is missing from toplevel).

I don't think it is the problem. If I delete

printf "%c", 16*index(h, substr($0, i, 1))+index(h, substr($0, i+1, 1))-17 

I have no problem. The following patch generates:

printf "%c", 16*index(h, substr($0, i, 1))+index(h, substr($0, i+1, 1))-17

in configrue. It looks like index and $0 are used by m4.


H.J.
--- libtool.m4.gcj	2007-05-26 11:42:16.000000000 -0700
+++ libtool.m4	2007-05-28 19:42:34.000000000 -0700
@@ -6737,18 +6737,55 @@ m4_defun([_LT_LANG_GCJ_CONFIG],
 [AC_REQUIRE([LT_PROG_GCJ])dnl
 AC_LANG_SAVE
 
-# Source file extension for Java test sources.
-ac_ext=java
+# Source file extension for Java test sources.  Actually, we use a list
+# of input files so that we can prepare binary .class files and keep
+# lt_simple_compile_test_code/lt_simple_link_test_code in ASCII.
+ac_ext=list
 
 # 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="class foo {}"
+# "class conftest_compile {}"
+# Eliminate NULs (for portability), and turn it into hex using
+#       tr \\000 \\377 < foo.class | od -x | sed s/^.......// | tr -d ' '
+lt_simple_compile_test_code='conftest_compile.class'
+awk 'BEGIN { h = "0123456789abcdef" }
+  {
+    for (i = 1; i <= length; i+=2)
+      printf "%c", 16*[index](h, substr([$]0, i, 1))+[index](h, substr([$]0, i+1, 1))-17
+  }' | tr \\377 \\000 > conftest_compile.class << EOF
+cafebabeffffff31ff0d0aff03ff0a07ff0b07ff0c01ff063c696e69743e01ff
+0328295601ff04436f646501ff0f4c696e654e756d6265725461626c6501ff0a
+536f7572636546696c6501ff15636f6e66746573745f636f6d70696c652e6a61
+76610cff04ff0501ff10636f6e66746573745f636f6d70696c6501ff106a6176
+612f6c616e672f4f626a656374ff20ff02ff03ffffffffff01ffffff04ff05ff
+01ff06ffffff1dff01ff01ffffff052ab7ff01b1ffffff01ff07ffffff06ff01
+ffffff01ff01ff08ffffff02ff09
+EOF
 
 # Code to be used in simple link tests
-lt_simple_link_test_code='public class conftest { public static void main(String[[]] argv) {}; }'
+# "public class conftest_link { public static void main(String[[]] argv) {}; }"
+lt_simple_link_test_code='conftest_link.class'
+awk 'BEGIN { h = "0123456789abcdef" }
+  {
+    for (i = 1; i <= length; i+=2)
+      printf "%c", 16*[index](h, substr([$]0, i, 1))+[index](h, substr([$]0, i+1, 1))-17
+  }' | tr \\377 \\000 > conftest_link.class << EOF
+cafebabeffffff31ff0f0aff03ff0c07ff0d07ff0e01ff063c696e69743e01ff
+0328295601ff04436f646501ff0f4c696e654e756d6265725461626c6501ff04
+6d61696e01ff16285b4c6a6176612f6c616e672f537472696e673b295601ff0a
+536f7572636546696c6501ff12636f6e66746573745f6c696e6b2e6a6176610c
+ff04ff0501ff0d636f6e66746573745f6c696e6b01ff106a6176612f6c616e67
+2f4f626a656374ff21ff02ff03ffffffffff02ff01ff04ff05ff01ff06ffffff
+1dff01ff01ffffff052ab7ff01b1ffffff01ff07ffffff06ff01ffffff01ff09
+ff08ff09ff01ff06ffffff19ffffff01ffffff01b1ffffff01ff07ffffff06ff
+01ffffff01ff01ff0affffff02ff0bff
+EOF
+
+lt_save_ac_compile="$ac_compile"
+ac_compile='$CC -c $CFLAGS $CPPFLAGS @conftest.$ac_ext >&5'
 
 # ltmain only uses $CC for tagged configurations so make sure $CC is set.
 _LT_TAG_COMPILER
@@ -6786,6 +6823,7 @@ if test -n "$compiler"; then
 fi
 
 AC_LANG_RESTORE
+ac_compile="$lt_save_ac_compile"
 CC="$lt_save_CC"
 ])# _LT_LANG_GCJ_CONFIG
 

Re: PATCH: PR libjava/32098: New libtool doesn't support libjava

[H. J. Lu]

On Mon, May 28, 2007 at 11:56:58AM -0400, Jack Howarth wrote:
> HJ,
>    Remember that Geoff's multilib fixes are in multi.m4
> so that you need to use that file. When I regenerated
> aclocal.m4, configure and Makefile.in for r120870, I
> used.
> 

The problem is the patch in

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

it causes aclocal/autoconf problems.  See

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


H.J.

Re: PATCH: PR libjava/32098: New libtool doesn't support libjava

[H. J. Lu]

On Mon, May 28, 2007 at 07:46:16PM -0700, H. J. Lu wrote:
> On Mon, May 28, 2007 at 03:58:29PM +0200, Andreas Schwab wrote:
> > "H. J. Lu" <hjl@lucon.org> writes:
> > 
> > > bash-3.1$ cd libjava
> > > bash-3.1$ autoconf
> > > /usr/bin/m4:configure.ac:450: ERROR: recursion limit of 1024 exceeded, use -L<N> to change it
> > > autom4te: /usr/bin/m4 failed with exit status: 1
> > 
> > Make sure that aclocal.m4 is correctly regenerated, using the right
> > version of ltdl.m4 (which is missing from toplevel).
> 
> I don't think it is the problem. If I delete
> 
> printf "%c", 16*index(h, substr($0, i, 1))+index(h, substr($0, i+1, 1))-17 
> 
> I have no problem. The following patch generates:
> 
> printf "%c", 16*index(h, substr($0, i, 1))+index(h, substr($0, i+1, 1))-17
> 
> in configrue. It looks like index and $0 are used by m4.
> 
> 

This patch allows me to run aclocal and autoconf. However, it still
doesn't work. But we can't use conftest* as Java class file name since
it will be removed after a test is done.  That means the second gcj
test will fail since those class files have been removed.  If we
rename them to something else, we should remove them after all gcj
tests are done.



H.J.
----
--- libtool.m4.gcj	2007-05-26 11:42:16.000000000 -0700
+++ libtool.m4	2007-05-28 20:34:17.000000000 -0700
@@ -6737,18 +6737,55 @@ m4_defun([_LT_LANG_GCJ_CONFIG],
 [AC_REQUIRE([LT_PROG_GCJ])dnl
 AC_LANG_SAVE
 
-# Source file extension for Java test sources.
-ac_ext=java
+# Source file extension for Java test sources.  Actually, we use a list
+# of input files so that we can prepare binary .class files and keep
+# lt_simple_compile_test_code/lt_simple_link_test_code in ASCII.
+ac_ext=list
 
 # 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="class foo {}"
+# "class conftest_compile {}"
+# Eliminate NULs (for portability), and turn it into hex using
+#       tr \\000 \\377 < foo.class | od -x | sed s/^.......// | tr -d ' '
+lt_simple_compile_test_code='conftest_compile.class'
+awk 'BEGIN { h = "0123456789abcdef" }
+  {
+    for (i = 1; i <= length; i+=2)
+      printf "%c", 16*[index](h, substr([$]0, i, 1))+[index](h, substr([$]0, i+1, 1))-17
+  }' << EOF | tr \\377 \\000 > conftest_compile.class
+cafebabeffffff31ff0d0aff03ff0a07ff0b07ff0c01ff063c696e69743e01ff
+0328295601ff04436f646501ff0f4c696e654e756d6265725461626c6501ff0a
+536f7572636546696c6501ff15636f6e66746573745f636f6d70696c652e6a61
+76610cff04ff0501ff10636f6e66746573745f636f6d70696c6501ff106a6176
+612f6c616e672f4f626a656374ff20ff02ff03ffffffffff01ffffff04ff05ff
+01ff06ffffff1dff01ff01ffffff052ab7ff01b1ffffff01ff07ffffff06ff01
+ffffff01ff01ff08ffffff02ff09
+EOF
 
 # Code to be used in simple link tests
-lt_simple_link_test_code='public class conftest { public static void main(String[[]] argv) {}; }'
+# "public class conftest_link { public static void main(String[[]] argv) {}; }"
+lt_simple_link_test_code='conftest_link.class'
+awk 'BEGIN { h = "0123456789abcdef" }
+  {
+    for (i = 1; i <= length; i+=2)
+      printf "%c", 16*[index](h, substr([$]0, i, 1))+[index](h, substr([$]0, i+1, 1))-17
+  }' << EOF | tr \\377 \\000 > conftest_link.class
+cafebabeffffff31ff0f0aff03ff0c07ff0d07ff0e01ff063c696e69743e01ff
+0328295601ff04436f646501ff0f4c696e654e756d6265725461626c6501ff04
+6d61696e01ff16285b4c6a6176612f6c616e672f537472696e673b295601ff0a
+536f7572636546696c6501ff12636f6e66746573745f6c696e6b2e6a6176610c
+ff04ff0501ff0d636f6e66746573745f6c696e6b01ff106a6176612f6c616e67
+2f4f626a656374ff21ff02ff03ffffffffff02ff01ff04ff05ff01ff06ffffff
+1dff01ff01ffffff052ab7ff01b1ffffff01ff07ffffff06ff01ffffff01ff09
+ff08ff09ff01ff06ffffff19ffffff01ffffff01b1ffffff01ff07ffffff06ff
+01ffffff01ff01ff0affffff02ff0bff
+EOF
+
+lt_save_ac_compile="$ac_compile"
+ac_compile='$CC -c $CFLAGS $CPPFLAGS @conftest.$ac_ext >&5'
 
 # ltmain only uses $CC for tagged configurations so make sure $CC is set.
 _LT_TAG_COMPILER
@@ -6786,6 +6823,7 @@ if test -n "$compiler"; then
 fi
 
 AC_LANG_RESTORE
+ac_compile="$lt_save_ac_compile"
 CC="$lt_save_CC"
 ])# _LT_LANG_GCJ_CONFIG
 

Re: PATCH: PR libjava/32098: New libtool doesn't support libjava

[Paolo Bonzini]

> This patch allows me to run aclocal and autoconf. However, it still
> doesn't work. But we can't use conftest* as Java class file name since
> it will be removed after a test is done.  That means the second gcj
> test will fail since those class files have been removed.  If we
> rename them to something else, we should remove them after all gcj
> tests are done.

Sounds like a nice plan.  Can you finish it?

Paolo

Re: PATCH: PR libjava/32098: New libtool doesn't support libjava

[H. J. Lu]

On Tue, May 29, 2007 at 09:07:49AM +0200, Paolo Bonzini wrote:
> 
> >This patch allows me to run aclocal and autoconf. However, it still
> >doesn't work. But we can't use conftest* as Java class file name since
> >it will be removed after a test is done.  That means the second gcj
> >test will fail since those class files have been removed.  If we
> >rename them to something else, we should remove them after all gcj
> >tests are done.
> 
> Sounds like a nice plan.  Can you finish it?

It doesn't work since gcj isn't functional at that time. configure
complains

configure:16060: /export/build/gnu/gcc-isa/build-x86_64-linux/gcc/gcj -B/export/build/gnu/gcc-isa/build-x86_64-linux/x86_64-unknown-linux-gnu/libjava/ -B/export/build/gnu/gcc-isa/build-x86_64-linux/gcc/ -c -O2 -g -O2 -fPIC @conftest.list >&5
gcjtest_compile.java:0: error: cannot find file for class java.lang.Object
gcjtest_compile.java:0: error: cannot find file for class java.lang.Object
gcjtest_compile.java: In class 'gcjtest_compile':
gcjtest_compile.java: In constructor '()':
gcjtest_compile.java:0: error: cannot find file for class
java.lang.Object
gcjtest_compile.java:0: error: class 'java.lang.Object' has no method named '<init>' matching signature '()V'
gcjtest_compile.java:0: confused by earlier errors, bailing out


H.J.

Re: PATCH: PR libjava/32098: New libtool doesn't support libjava

[H. J. Lu]

On Tue, May 29, 2007 at 06:47:07AM -0700, H. J. Lu wrote:
> On Tue, May 29, 2007 at 09:07:49AM +0200, Paolo Bonzini wrote:
> > 
> > >This patch allows me to run aclocal and autoconf. However, it still
> > >doesn't work. But we can't use conftest* as Java class file name since
> > >it will be removed after a test is done.  That means the second gcj
> > >test will fail since those class files have been removed.  If we
> > >rename them to something else, we should remove them after all gcj
> > >tests are done.
> > 
> > Sounds like a nice plan.  Can you finish it?
> 
> It doesn't work since gcj isn't functional at that time. configure
> complains
> 
> configure:16060: /export/build/gnu/gcc-isa/build-x86_64-linux/gcc/gcj -B/export/build/gnu/gcc-isa/build-x86_64-linux/x86_64-unknown-linux-gnu/libjava/ -B/export/build/gnu/gcc-isa/build-x86_64-linux/gcc/ -c -O2 -g -O2 -fPIC @conftest.list >&5
> gcjtest_compile.java:0: error: cannot find file for class java.lang.Object
> gcjtest_compile.java:0: error: cannot find file for class java.lang.Object
> gcjtest_compile.java: In class 'gcjtest_compile':
> gcjtest_compile.java: In constructor '()':
> gcjtest_compile.java:0: error: cannot find file for class
> java.lang.Object
> gcjtest_compile.java:0: error: class 'java.lang.Object' has no method named '<init>' matching signature '()V'
> gcjtest_compile.java:0: confused by earlier errors, bailing out
> 

Since C and C++ are the only compilers available when building
libjava, we can't use anything else to test gcj features. Classpath
is a little different since libtool.m4 in classpath isn't really used
by libjava, it doesn't need my hack.


H.J.

Re: PATCH: PR libjava/32098: New libtool doesn't support libjava

[Paolo Bonzini]

>> It doesn't work since gcj isn't functional at that time. configure
>> complains
>>
>> configure:16060: /export/build/gnu/gcc-isa/build-x86_64-linux/gcc/gcj -B/export/build/gnu/gcc-isa/build-x86_64-linux/x86_64-unknown-linux-gnu/libjava/ -B/export/build/gnu/gcc-isa/build-x86_64-linux/gcc/ -c -O2 -g -O2 -fPIC @conftest.list >&5
>> gcjtest_compile.java:0: error: cannot find file for class java.lang.Object
>> gcjtest_compile.java:0: error: cannot find file for class java.lang.Object
>> gcjtest_compile.java: In class 'gcjtest_compile':
>> gcjtest_compile.java: In constructor '()':
>> gcjtest_compile.java:0: error: cannot find file for class
>> java.lang.Object
>> gcjtest_compile.java:0: error: class 'java.lang.Object' has no method named '<init>' matching signature '()V'
>> gcjtest_compile.java:0: confused by earlier errors, bailing out
> 
> Since C and C++ are the only compilers available when building
> libjava, we can't use anything else to test gcj features. Classpath
> is a little different since libtool.m4 in classpath isn't really used
> by libjava, it doesn't need my hack.

You need to pass -fclasspath= -fbootclasspath=$srcdir/classpath/lib 
-fbootstrap-classes, or something like that.  Which I didn't know before 
writing this message; I just grepped libjava/Makefile.am for GCJFLAGS.

Your complaining is based on a false hypothesis.  gcj *is* functional as 
a bytecode-to-native compiler when building libjava; and it is also 
functional as a source-to-native compiler only if you have ecj installed.

Paolo

Re: PATCH: PR libjava/32098: New libtool doesn't support libjava

[Paolo Bonzini]

>> It doesn't work since gcj isn't functional at that time. configure
>> complains
>>
>> configure:16060: /export/build/gnu/gcc-isa/build-x86_64-linux/gcc/gcj -B/export/build/gnu/gcc-isa/build-x86_64-linux/x86_64-unknown-linux-gnu/libjava/ -B/export/build/gnu/gcc-isa/build-x86_64-linux/gcc/ -c -O2 -g -O2 -fPIC @conftest.list >&5
>> gcjtest_compile.java:0: error: cannot find file for class java.lang.Object
>> gcjtest_compile.java:0: error: cannot find file for class java.lang.Object
>> gcjtest_compile.java: In class 'gcjtest_compile':
>> gcjtest_compile.java: In constructor '()':
>> gcjtest_compile.java:0: error: cannot find file for class
>> java.lang.Object
>> gcjtest_compile.java:0: error: class 'java.lang.Object' has no method named '<init>' matching signature '()V'
>> gcjtest_compile.java:0: confused by earlier errors, bailing out
> 
> Since C and C++ are the only compilers available when building
> libjava, we can't use anything else to test gcj features. Classpath
> is a little different since libtool.m4 in classpath isn't really used
> by libjava, it doesn't need my hack.

You need to pass -fclasspath= -fbootclasspath=$srcdir/classpath/lib 
-fbootstrap-classes, or something like that.  Which I didn't know before 
writing this message; I just grepped libjava/Makefile.am for GCJFLAGS.

Your complaining is based on a false hypothesis.  gcj *is* functional as 
a bytecode-to-native compiler when building libjava; and it is also 
functional as a source-to-native compiler only if you have ecj installed.

Paolo

Re: PATCH: PR libjava/32098: New libtool doesn't support libjava

[H. J. Lu]

On Tue, May 29, 2007 at 04:21:22PM +0200, Paolo Bonzini wrote:
> 
> >>It doesn't work since gcj isn't functional at that time. configure
> >>complains
> >>
> >>configure:16060: /export/build/gnu/gcc-isa/build-x86_64-linux/gcc/gcj 
> >>-B/export/build/gnu/gcc-isa/build-x86_64-linux/x86_64-unknown-linux-gnu/libjava/ -B/export/build/gnu/gcc-isa/build-x86_64-linux/gcc/ -c -O2 -g -O2 -fPIC @conftest.list >&5
> >>gcjtest_compile.java:0: error: cannot find file for class java.lang.Object
> >>gcjtest_compile.java:0: error: cannot find file for class java.lang.Object
> >>gcjtest_compile.java: In class 'gcjtest_compile':
> >>gcjtest_compile.java: In constructor '()':
> >>gcjtest_compile.java:0: error: cannot find file for class
> >>java.lang.Object
> >>gcjtest_compile.java:0: error: class 'java.lang.Object' has no method 
> >>named '<init>' matching signature '()V'
> >>gcjtest_compile.java:0: confused by earlier errors, bailing out
> >
> >Since C and C++ are the only compilers available when building
> >libjava, we can't use anything else to test gcj features. Classpath
> >is a little different since libtool.m4 in classpath isn't really used
> >by libjava, it doesn't need my hack.
> 
> You need to pass -fclasspath= -fbootclasspath=$srcdir/classpath/lib 
> -fbootstrap-classes, or something like that.  Which I didn't know before 
> writing this message; I just grepped libjava/Makefile.am for GCJFLAGS.
> 
> Your complaining is based on a false hypothesis.  gcj *is* functional as 
> a bytecode-to-native compiler when building libjava; and it is also 
> functional as a source-to-native compiler only if you have ecj installed.

See

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

Gcj isn't available for compile-and-link test when building libjava.


H.J.

Re: PATCH: PR libjava/32098: New libtool doesn't support libjava

[Paolo Bonzini]

> Gcj isn't available for compile-and-link test when building libjava.

I found a solution, which is to add a ltgcc.m4 file to the toplevel, 
where we can override macros as we wish.  For example, you can put a 
copy of the Java configuration macro there with your hack.  I will 
approve such a patch.

Paolo

Re: PATCH: PR libjava/32098: New libtool doesn't support libjava

[Peter O'Gorman]

On Wed, 2007-05-30 at 08:09 +0200, Paolo Bonzini wrote:
> > Gcj isn't available for compile-and-link test when building libjava.
> 
> I found a solution, which is to add a ltgcc.m4 file to the toplevel, 
> where we can override macros as we wish.  For example, you can put a 
> copy of the Java configuration macro there with your hack.  I will 
> approve such a patch.

Another alternative would be to pushdef([TROUBLESOME_MARCO],[patched
definition]) in the configure.ac.

If gcc is likely to need to override more than a couple of macros then a
new .m4 is probably a better idea.

Peter

Re: PATCH: PR libjava/32098: New libtool doesn't support libjava

[H. J. Lu]

On Wed, May 30, 2007 at 08:09:25AM +0200, Paolo Bonzini wrote:
> >Gcj isn't available for compile-and-link test when building libjava.
> 
> I found a solution, which is to add a ltgcc.m4 file to the toplevel, 
> where we can override macros as we wish.  For example, you can put a 
> copy of the Java configuration macro there with your hack.  I will 
> approve such a patch.
> 

I have no idea how to set it up.

BTW, with this scheme, when we update libtool, we have to make
sure that ltgcc.m4 is in sync. I don't see it is much different
from my hack. You have to do it manually in both cases.


H.J.

Re: PATCH: PR libjava/32098: New libtool doesn't support libjava

[Paolo Bonzini]

H. J. Lu wrote:
> On Wed, May 30, 2007 at 08:09:25AM +0200, Paolo Bonzini wrote:
>>> Gcj isn't available for compile-and-link test when building libjava.
>> I found a solution, which is to add a ltgcc.m4 file to the toplevel, 
>> where we can override macros as we wish.  For example, you can put a 
>> copy of the Java configuration macro there with your hack.  I will 
>> approve such a patch.
> 
> I have no idea how to set it up.

Please stop this "I have no idea" attitude, let's try to be constructive.

To test it, you just create ltgcc.m4 in toplevel (both gcc and src), and 
rerun aclocal in libjava.  Then we'll have to rerun aclocal manually in 
all directories, but let's first make a working patch.

> BTW, with this scheme, when we update libtool, we have to make
> sure that ltgcc.m4 is in sync. I don't see it is much different
> from my hack. You have to do it manually in both cases.

I can tell you that this macro is not going to change often.

Paolo

Re: PATCH: PR libjava/32098: New libtool doesn't support libjava

[H. J. Lu]

On Wed, May 30, 2007 at 04:17:28PM +0200, Paolo Bonzini wrote:
> H. J. Lu wrote:
> >On Wed, May 30, 2007 at 08:09:25AM +0200, Paolo Bonzini wrote:
> >>>Gcj isn't available for compile-and-link test when building libjava.
> >>I found a solution, which is to add a ltgcc.m4 file to the toplevel, 
> >>where we can override macros as we wish.  For example, you can put a 
> >>copy of the Java configuration macro there with your hack.  I will 
> >>approve such a patch.
> >
> >I have no idea how to set it up.
> 
> Please stop this "I have no idea" attitude, let's try to be constructive.

I have been very patient up to now. Why can't you try your own idea?

> 
> To test it, you just create ltgcc.m4 in toplevel (both gcc and src), and 
> rerun aclocal in libjava.  Then we'll have to rerun aclocal manually in 
> all directories, but let's first make a working patch.
> 

I tried m4_rename and m4_pushdef in libjava like

--- configure.ac.ltgcc	2007-05-28 20:04:33.000000000 -0700
+++ configure.ac	2007-05-30 06:56:44.000000000 -0700
@@ -431,6 +431,9 @@ dnl gjdoc?
 dnl gtk-cairo -- just export here...
 dnl --enable-regen-headers?
 
+m4_rename([_LT_LANG_GCJ_CONFIG], [_LT_LANG_GCJ_CONFIG_renamed])
+m4_rename([_LTGCC_LANG_GCJ_CONFIG], [_LT_LANG_GCJ_CONFIG])
+
 # Only use libltdl for non-newlib builds.
 if test "x${with_newlib}" = "x" || test "x${with_newlib}" = "xno"; then
    AC_LIBLTDL_CONVENIENCE

aclocal won't include ltgcc.m4. When I include it in configure.ac,
it still doesn't work. The order of ltgcc.m4 and libtool.m4 may be
important.

Sorry, I have too many other gcc things to deal with at the moment. I
don't think I can spend more time on this.


H.J.

PATCH: PR libjava/32098: New libtool doesn't support libjava

[H. J. Lu]

New libtool calls gcj to test gcj features. However, gcj isn't
fully functional when building libjava since ecj1 isn't available.
As the result, libtool created for libjava isn't really correct.
This patch uses gcc to test gcj features like PIC and "-c -o".


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

	PR libjava/32098
	* libtool.m4: Use gcc to test gcj features.

--- libtool.m4.gcj	2007-05-24 09:41:43.000000000 -0700
+++ libtool.m4	2007-05-27 09:07:11.000000000 -0700
@@ -6757,9 +6757,14 @@ _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])
@@ -6786,7 +6791,6 @@ if test -n "$compiler"; then
 fi
 
 AC_LANG_RESTORE
-CC="$lt_save_CC"
 ])# _LT_LANG_GCJ_CONFIG