gmane.comp.java.classpath.patches

ask help about cross complier of supportting java

阿林 — 2012-12-27T06:32:46

 

 hi friends,

I want to build cross compiler of gcc of 4.4.4. I can built success for c,c++. But when I try  to add language of java. I failed. I also read the document , the cross section is too short and non detailed. In the document, only "If the cross compiler is to be built with support for the Java programming language and the ability to compile .java source files is desired, the installed native compiler used to build the cross compiler needs to be the same GCC version as the cross compiler. In addition the cross compiler needs to be configured with --with-ecj-jar=... ". 
Since I use ppc64 and try to build ppc. I don't know how to use this option. I use the ecj of 64-bit package,  I am not sure if it is ok. I can not built success. I have no idea how to process next. Maybe I am wrong at first  for use incorrect parameter.  So I write the email to you and try to get help from gcc group.  I hope get your suggestions and how I can built out gcj by cross complier.  Thank you very much!

Best regards,

[PATCH] Add support for aarch64

Andreas Schwab — 2013-03-27T11:57:52

Signed-off-by: Andreas Schwab <schwab< at >suse.de>
---
 ChangeLog              | 4 ++++
 native/fdlibm/ieeefp.h | 8 ++++++++
 2 files changed, 12 insertions(+)

diff --git a/ChangeLog b/ChangeLog
index e26f627..d547c7a 100644
--- a/ChangeLog
+++ b/ChangeLog
< at >< at > -1,3 +1,7 < at >< at >
+2013-03-27  Andreas Schwab  <schwab< at >suse.de>
+
+* native/fdlibm/ieeefp.h: Add support for aarch64.
+
 2013-03-12  Pekka Enberg <penberg< at >kernel.org>
 
 * autogen.sh:
diff --git a/native/fdlibm/ieeefp.h b/native/fdlibm/ieeefp.h
index c230bbb..7ef2ae7 100644
--- a/native/fdlibm/ieeefp.h
+++ b/native/fdlibm/ieeefp.h
< at >< at > -4,6 +4,14 < at >< at >
 #ifndef __IEEE_BIG_ENDIAN
 #ifndef __IEEE_LITTLE_ENDIAN
 
+#ifdef __aarch64__
+#ifdef __AARCH64EB__
+#define __IEEE_BIG_ENDIAN
+#else
+#define __IEEE_LITTLE_ENDIAN
+#endif
+#endif
+
 #ifdef __alpha__
 #define __IEEE_LITTLE_ENDIAN
 #endif

Re: [RFC/PATCH] Check for gettext m4 macros in autogen.sh

Andrew Hughes — 2013-03-13T10:51:41

----- Original Message -----

Our script does use autoreconf among other things. It's for developers
working with the repository to generate the necessary autotools files
that would be included in a distribution tarball.

The change looks fine, Pekka.

Re: [RFC/PATCH] Check for gettext m4 macros in autogen.sh

Mark Wielaard — 2013-03-13T10:39:32

Yes it is fine. We provide autogen.sh.

These days for a new project one would probably use autoreconf provided
by autoconf. But that didn't exist when we introduced our own autogen.sh
script.

Cheers,

Mark

Re: [RFC/PATCH] Check for gettext m4 macros inautogen.sh

Brian Jones — 2013-03-13T02:27:34

I'm sorry I'm not a good one to review this.  They changed the auto*
tools quite a bit since I used to mess with them.  Is autogen.sh
something auto* creates, just wondering if it is okay to modify...

On Tue, Mar 12, 2013 at 2:47 PM, Pekka Enberg <penberg< at >kernel.org> wrote:

[RFC/PATCH] Check for gettext m4 macros in autogen.sh

Pekka Enberg — 2013-03-12T18:47:15

If gettext-devel package is not installed on Fedora, autogen.sh fails as
follows:

  [penberg< at >tux classpath]$ sh autogen.sh
  configure.ac:505: warning: AC_LIB_PREPARE_PREFIX is m4_require'd but not m4_defun'd
  m4/iconv.m4:11: AM_ICONV_LINKFLAGS_BODY is expanded from...
  m4/iconv.m4:22: AM_ICONV_LINK is expanded from...
  m4/iconv.m4:77: AM_ICONV is expanded from...

Make the script more user fiendly by explicitly checking for the
presence of gettext.m4 in the system.

Cc: Andrew John Hughes  <gnu_andrew< at >member.fsf.org>
Cc: Brian Jones <cbjones1< at >gmail.com>
Signed-off-by: Pekka Enberg <penberg< at >kernel.org>
---
 ChangeLog  |    5 +++++
 autogen.sh |    7 +++++++
 2 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 289a979..e26f627 100644
--- a/ChangeLog
+++ b/ChangeLog
< at >< at > -1,3 +1,8 < at >< at >
+2013-03-12  Pekka Enberg <penberg< at >kernel.org>
+
+* autogen.sh:
+Check that gettext.m4 is installed.
+
 2013-03-09  Pekka Enberg <penberg< at >kernel.org>
 
 * .gitignore: Exclude autogen-ge

Re: [RFC/PATCH] Add autogen-generated files togitignore

Pekka Enberg — 2013-03-11T13:49:25

I merged the variant suggested by Mark. Thanks!

Re: [RFC/PATCH] AnnotationInvocationHandler type parametrization

Andrew Hughes — 2013-03-11T13:22:38

----- Original Message -----

I'd rather we left this until after the next release and updated all VM
interfaces to 1.5 level at the same time.  That's why I've deliberately
avoided updating them so far.

Take 0.99.1 as being the watershed for pre-1.5 VM interfaces.

Re: [RFC/PATCH] Add autogen-generated filestogitignore

Andrew Hughes — 2013-03-11T13:20:49

----- Original Message -----

Fine by me.  I've been planning to commit the same, but there's always something I'm working on.

Re: [RFC/PATCH] AnnotationInvocationHandler type parametrization

Mark Wielaard — 2013-03-09T13:01:46

There are some other small changes in the class file format, class
access flags, attributes. But the main reason was source compatibility.
It was convenient if the VM and VM interface classes could be build with
any java language compiler out there (even these days only javac and ecj
support 1.5+ fully) since they were often build independently from the
rest of the core classes during bootstrapping of the VM. And keeping the
core class VM interface as simple as possible, since some of the VM
interface classes could be overridden by a VM is easier when not using
generics.

Anyway, I think this class isn't really a VM interface class, so it
should be fine.

I guess I am just not a big fan of using fancy new (haha, it is 2013
Mark...) language features unless really necessary.

Cheers,

Mark

Re: [RFC/PATCH] AnnotationInvocationHandler typeparametrization

Pekka Enberg — 2013-03-09T10:26:20

Hello Mark,

On Sat, Mar 09, 2013 at 11:36:13AM +0200, Pekka Enberg wrote:

On Sat, Mar 9, 2013 at 12:09 PM, Mark Wielaard <mark< at >klomp.org> wrote:

It shouldn't make any difference to the VM classloader because of type
erasure. What am I missing?

                        Pekka

Re: [RFC/PATCH] AnnotationInvocationHandler type parametrization

Mark Wielaard — 2013-03-09T10:09:09

Generally we avoided generics for VM interface files, so VMs can ignore
any "modern" class format extensions in their bootstrap classes.
This class probably doesn't officially count as one of the VM interface
ones, just as a convenience class. So I think this is fine.

Thanks,

Mark

Re: [RFC/PATCH] Add autogen-generated files togitignore

Mark Wielaard — 2013-03-09T09:59:07

This looks fine, these are all libtool files.
Might it make sense to ignore m4/libtool and m4/lt*m4?
Or does libtool only ever generate these 5 files?

Thanks,

Mark

[RFC/PATCH] AnnotationInvocationHandler typeparametrization

Pekka Enberg — 2013-03-09T09:36:13

Type parametrize uses of generic types in AnnotationInvocationHandler.

Signed-off-by: Pekka Enberg <penberg< at >kernel.org>
---
 ChangeLog                                          |   10 +++++++
 .../annotation/AnnotationInvocationHandler.java    |   28 ++++++++++----------
 2 files changed, 24 insertions(+), 14 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 289a979..08f2d6e 100644
--- a/ChangeLog
+++ b/ChangeLog
< at >< at > -1,5 +1,15 < at >< at >
 2013-03-09  Pekka Enberg <penberg< at >kernel.org>
 
+* sun/reflect/annotation/AnnotationInvocationHandler.java:
+(AnnotationInvocationHandler(Class, Map)): Add type parameters.
+(create(Class, Map)): Add type parameters.
+(equals(Class, Map)): Add type parameters.
+(hashCode(Class, Map)): Add type parameters.
+(toString(Class, Map)): Add type parameters.
+(getBoxedReturnType(Method)): Add type parameters.
+
+2013-03-09  Pekka Enberg <penberg< at >kernel.org>
+
 * .gitignore: Exclude autogen-generated files.
 
 2013-03-04  Andrew John Hughes  <gnu_andrew< at >member.fsf.org>
diff --g

[RFC/PATCH] Add autogen-generated files to gitignore

Pekka Enberg — 2013-03-09T09:03:22

Make sure "git status" does not show up files after autogen.sh has been
run.

Signed-off-by: Pekka Enberg <penberg< at >kernel.org>
---
 .gitignore |    5 +++++
 ChangeLog  |    4 ++++
 2 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/.gitignore b/.gitignore
index 817e215..1b3d546 100644
--- a/.gitignore
+++ b/.gitignore
< at >< at > -21,3 +21,8 < at >< at > install-sh
 missing
 mkinstalldirs
 INSTALL
+m4/libtool.m4
+m4/ltoptions.m4
+m4/ltsugar.m4
+m4/ltversion.m4
+m4/lt~obsolete.m4
diff --git a/ChangeLog b/ChangeLog
index b08c5af..289a979 100644
--- a/ChangeLog
+++ b/ChangeLog
< at >< at > -1,3 +1,7 < at >< at >
+2013-03-09  Pekka Enberg <penberg< at >kernel.org>
+
+* .gitignore: Exclude autogen-generated files.
+
 2013-03-04  Andrew John Hughes  <gnu_andrew< at >member.fsf.org>
 
 * gnu/classpath/Pair.java:

Re: tagging classpath for GCC import

Mark Wielaard — 2012-12-04T08:35:20

It is pretty convenient to have all old tags around.
I haven't recovered everything yet (I am still unclear of to get the
branches back). But normally I just tag the tree as soon as someone
works on importing it into libgcj so we have a point of reference.


When the bug fixes are in please feel free to tag the tree again.
Are any of these show stoppers for importing now?

Thanks,

Mark

Re: tagging classpath for GCC import

Andrew Hughes — 2012-12-03T14:22:30

----- Original Message -----

Could we not have discussed this first?

I've been working on this for a while already and there's some more bug fixes
I wanted to get in before tagging and merging.

tagging classpath for GCC import

Mark Wielaard — 2012-12-02T21:20:44

Hi,

Matthias wanted to import the latest classpath from git into libgcj
so I have pushed a tag (libgcj-import-20121202) for current HEAD.
(Note for future reference, to push a tag one uses git push --tags,
with just git push the tag stays local.)

It seems the git import from CVS lost the old tags. Does anybody
know of a way to get them from the original CVS history into the
git repository?

Thanks,

Mark

Re: Patch fixing bugs in several StrictMath methods

Ivan Maidanski — 2012-11-07T13:43:31

Hi Pekka,

No problem. Thanks anyway.

The proposed test fails in Classpath but succeeds in OpenJDK. The original Classpath StrictMath code has been ported from fdlibm and a dozen of bugs emerged at that phase. The proposed code should fix discovered bugs. Of course, the code contains math expressions and, thus, no easy to read and review.

Regards,
Ivan

Wed, 7 Nov 2012 15:04:48 +0200 Pekka Enberg <penberg< at >kernel.org>:





On Sat, Oct 27, 2012 at 6:10 PM, Ivan Maidanski <ivmai< at >mail.ru> wrote:
I'm afraid I'll have to leave StrictMath reviewing for Andrew. I
really have no clue what that code is supposed to be doing. ;-)
                        Pekka

Re: Patch fixing bugs in several StrictMath methods

Pekka Enberg — 2012-11-07T13:04:48

Hi Ivan,

On Sat, Oct 27, 2012 at 6:10 PM, Ivan Maidanski <ivmai< at >mail.ru> wrote:

I'm afraid I'll have to leave StrictMath reviewing for Andrew. I
really have no clue what that code is supposed to be doing. ;-)

                        Pekka

Re: [RFC PATCH 4/4]Fixjava/lang/String.codePoint{At|Before} exception types

Andrew Hughes — 2012-10-30T19:23:49

----- Original Message -----

The checks added to codePointBefore here are wrong and broke the OpenJDK
build:

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

The specification says:

"IndexOutOfBoundsException - if the index argument is less than 1 or greater than the length of this string."

whereas the code above has clearly just been copied from codePointAt.

I'll commit a fix.