[gentoo-java] work on gcj for gentoo

[gentoo-java] work on gcj for gentoo

[Hanno Meyer-Thurow]

Hi list!
I would like to work on gcj for Gentoo.
I spoke with Andrew Cowie. He suggested me to send my ideas and
questions to this list to discuss.

I know gcj is tricky. It has various issues. Still, it is quite interesting
to work on gcj. But as gcj is in portage right now it is hard to use for
an ebuild writer like myself. Just two main issues:

	* dependency tracking
	* JDK-like environment

However, I may write my ideas and questions:

I thought in a gcj-4.1 / ecj combination. Use ecj to bytecompile Java
source to jar with gcj as backend. Then use gcj to create native
executables or libraries out of that jar files. Creating a database
via gcj-dbtool for jar / native code resolution. If possible Java to
native.

The steps to take to get there

	* get gcj-jdk in portage
	* use ecj as gcjs bytecompiler
	* handle it via Gentoos java config
	  (gcj bytecompile is broken,
	  see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18131)

(later)

	* Java to native compilation
	* utilize gcj-dbtool for jar / native code resolution
	  (Whatever way it is wanted.)

To stay sane we want to hack the ant-core dependency out of
eclipse-ecj package. Just try to compile ant-core with gcj. I have
ugly hacks (gcc PR19870) for ant-core-1.6.2 to bytecompile with gcj.

	No way.

Then I have to get ant-core-1.6.5 to bytecompile with gcj / ecj which
fails right now - did not yet investigate any further. After these steps
are done we have the base (for interested ones to test gcj).

	I am no Java programmer.
	I do packaging stuff and ugly hacking. ;)

I will try to integrate gcj into Gentoos next Java config utility.
Just not to do the work of integration twice.

What I did already:

	* tweaked Andrew's gcj-jdk ebuild
	-> ebuild / eclass split
	* gcj-ecj ebuild
	-> Java to native: ecj binary

The very next steps should be:

	* better gcj-jdk ebuild
	* fix ant-core issue with ecj

Then, get back to plan.

Reference - my overlay for these two ebuilds:
http://geki.ath.cx/hacks/gcj-overlay-2.tar.bz2


Thanks in advance for help!


Regards,
Hanno
-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] work on gcj for gentoo

[Karl Trygve Kalleberg]

Hanno Meyer-Thurow wrote:
> Hi list!
> I would like to work on gcj for Gentoo.

Excellent! We need all the help we can get.

> I thought in a gcj-4.1 / ecj combination. Use ecj to bytecompile Java
> source to jar with gcj as backend. Then use gcj to create native
> executables or libraries out of that jar files. Creating a database
> via gcj-dbtool for jar / native code resolution. If possible Java to
> native.

The problem with this approach is your resulting programs will be
potentially rather slow.

While gcj can indeed compile .class files (inside .jars) to binary, I've
been told it can produce the most efficient of results. The source code
is much richer in structure than the bytecode, and opens up for many
effective optimizations which could only be reached through
"idiom-recognition" (which doesn't exist for gcj yet, afaik) of the
.class files.

I suspect that you shouldn't give up on using gcj as a source compiler
quite yet. This story may evolve with the whole ecj/gcjx/GPLv3 debate.

Just my 0.02CAD,

-- Karl T
-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] work on gcj for gentoo

[Hanno Meyer-Thurow]

On Tue, 21 Feb 2006 16:42:51 +0100
Karl Trygve Kalleberg <karltk@gentoo.org> wrote:

> Excellent! We need all the help we can get.

Whatever I can do.

> > ... Then use gcj to create native
> > executables or libraries out of that jar files. Creating a database
> > via gcj-dbtool for jar / native code resolution. If possible Java to
> > native.
> 
> The problem with this approach is your resulting programs will be
> potentially rather slow.

I got an example from OOo for jar to native compilation.
It may not be lightening-fast but ...

http://www.openoffice.org/issues/show_bug.cgi?id=54692

... there it still speeds up the process.

What is done there:

	* jars -> native libraries
	* .java -> native binaray

What used to do a JVM with jars now does a native binary with jars
compiled to native libs. Time went down from 3h40 to 2h45.

I hit a oom-killer feature of gij - run as JVM - there on my 512MB ram
testbox. If you compile that Java source to native that oom-kill
vanishes.

Still, just an example.

> While gcj can indeed compile .class files (inside .jars) to binary, I've
> been told it can produce the most efficient of results. The source code
> is much richer in structure than the bytecode, and opens up for many
> effective optimizations which could only be reached through
> "idiom-recognition" (which doesn't exist for gcj yet, afaik) of the
> .class files.

In a perfect world ... ;)

> I suspect that you shouldn't give up on using gcj as a source compiler
> quite yet. This story may evolve with the whole ecj/gcjx/GPLv3 debate.

I use gcj successfully on my testbox.
As far as it is possible. And with ecj as bytecompiler all my ugly hacks will
be a part of the past.

Only trouble I have actually is eclipse-sdk. Another oom-killer at runtime.
May be I find the time to get it to native code somehow.


Regards,
Hanno
-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] work on gcj for gentoo

[Karl Trygve Kalleberg]

Hanno Meyer-Thurow wrote:
> On Tue, 21 Feb 2006 16:42:51 +0100

>>The problem with this approach is your resulting programs will be
>>potentially rather slow.

Actually, I checked with the RedHat guys, and re-read the ECJ post by
Tom. Apparently, changes to GCC in the last years now allow pretty
efficient compilation of the bytecode after all. Yay!

> Only trouble I have actually is eclipse-sdk. Another oom-killer at runtime.
> May be I find the time to get it to native code somehow.

Andrew Overholt maintains the Eclipse rpms for Fedora. They do heavy
patching of Eclipse to get all of it working. You want might want to
take a look at his work:

http://people.redhat.com/overholt/eclipse/


-- Karl T
-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] work on gcj for gentoo

[Joshua Nichols]

Hanno Meyer-Thurow wrote:
> Hi list!
> I would like to work on gcj for Gentoo.
> I spoke with Andrew Cowie. He suggested me to send my ideas and
> questions to this list to discuss.
>
> I know gcj is tricky. It has various issues. Still, it is quite interesting
> to work on gcj. But as gcj is in portage right now it is hard to use for
> an ebuild writer like myself. Just two main issues:
>
> 	* dependency tracking
> 	* JDK-like environment
>
>   
For JDK-like environment, redhat has done much work on this already. It 
is, surprisingly enough, called java-gcj-compat. Take a look at the 
jpackage rpm  for it [1]. You can find other sites for java-gcj-compat, 
but the jpackage rpm seems to have the highest version I was able to find.

> However, I may write my ideas and questions:
>
> I thought in a gcj-4.1 / ecj combination. Use ecj to bytecompile Java
> source to jar with gcj as backend. Then use gcj to create native
> executables or libraries out of that jar files. Creating a database
> via gcj-dbtool for jar / native code resolution. If possible Java to
> native.
>
>   
java-gcj-compat actually uses ecj internally, along with some other magic.
> The steps to take to get there
>
> 	* get gcj-jdk in portage
> 	* use ecj as gcjs bytecompiler
> 	* handle it via Gentoos java config
> 	  (gcj bytecompile is broken,
> 	  see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18131)
>
> (later)
>
> 	* Java to native compilation
> 	* utilize gcj-dbtool for jar / native code resolution
> 	  (Whatever way it is wanted.)
>
> To stay sane we want to hack the ant-core dependency out of
> eclipse-ecj package. Just try to compile ant-core with gcj. I have
> ugly hacks (gcc PR19870) for ant-core-1.6.2 to bytecompile with gcj.
>
>   
This shouldn't be much of a problem. The build.xml is pretty trivial, so 
you should be able to replicate it using javac and jar.
> 	No way.
>
> Then I have to get ant-core-1.6.5 to bytecompile with gcj / ecj which
> fails right now - did not yet investigate any further. After these steps
> are done we have the base (for interested ones to test gcj).
>
> 	I am no Java programmer.
> 	I do packaging stuff and ugly hacking. ;)
>
> I will try to integrate gcj into Gentoos next Java config utility.
> Just not to do the work of integration twice.
>
>   
There really isn't much 'integration' involved per se. You mostly just 
have to create an env file that contains information about JAVA_HOME, 
PATH, etc. Take a look at existing jdk/jre packages.
> What I did already:
>
> 	* tweaked Andrew's gcj-jdk ebuild
> 	-> ebuild / eclass split
> 	* gcj-ecj ebuild
> 	-> Java to native: ecj binary
>
> The very next steps should be:
>
> 	* better gcj-jdk ebuild
> 	* fix ant-core issue with ecj
>
> Then, get back to plan.
>
> Reference - my overlay for these two ebuilds:
> http://geki.ath.cx/hacks/gcj-overlay-2.tar.bz2
>
>
> Thanks in advance for help!
>
>
> Regards,
> Hanno
>   

A few other things...

I'm not fond of the name gcj-jdk. The ebuild Andrew made was just for 
gcj itself, without the Java compatibility stuff, iirc. -jdk suggests 
that it provides a usable JDK, which it doesn't as it was.

Speaking of which, I think the added compatibility layer (for javac, 
java, etc) should be a separate package. I'm not sure if this was your 
intention or not. Either way, it would make sense, since you would most 
likely be able to use the same layer for different versions of gcj.

Hope this helps,

- Josh
-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] work on gcj for gentoo

[Joshua Nichols]

> For JDK-like environment, redhat has done much work on this already. 
> It is, surprisingly enough, called java-gcj-compat. Take a look at the 
> jpackage rpm  for it [1]. You can find other sites for 
> java-gcj-compat, but the jpackage rpm seems to have the highest 
> version I was able to find.

Forgot to include the URL... http://jpackage.org/rpm.php?id=1816
-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] work on gcj for gentoo

[Hanno Meyer-Thurow]

On Tue, 21 Feb 2006 10:45:58 -0500
Joshua Nichols <nichoj@gentoo.org> wrote:

> For JDK-like environment, redhat has done much work on this already. It 
> is, surprisingly enough, called java-gcj-compat. Take a look at the 
> jpackage rpm  for it [1]. You can find other sites for java-gcj-compat, 
> but the jpackage rpm seems to have the highest version I was able to find.

I did test java-gcj-compat already. It is of no use other than
java/javac links to gij/gcj. If that is what you want I may add that
symlinks to the ebuild. Besides that I work on OOo2. There you
need a JDK-like environment with gij/gcj and not java/javac
executables. As far as I looked at applications they look for gij/gcj
instead of java/javac then. So I do not see any use of that
java-gcj-compat package. It produces more work and things get
even more ugly.

As for ecj applications have --with-ecj switch or alike.
I will have a look on gcj/ecj issue for applications after
ant-core-1.6.5 merged with ecj.

> This shouldn't be much of a problem. The build.xml is pretty trivial, so 
> you should be able to replicate it using javac and jar.

True. Hacked up a build.sh for ecj native version already.

> There really isn't much 'integration' involved per se. You mostly just 
> have to create an env file that contains information about JAVA_HOME, 
> PATH, etc. Take a look at existing jdk/jre packages.

That would be great. I will see.

> I'm not fond of the name gcj-jdk. The ebuild Andrew made was just for 
> gcj itself, without the Java compatibility stuff, iirc. -jdk suggests 
> that it provides a usable JDK, which it doesn't as it was.

Well, I would just say gcj is a bit different than usual JDKs.
I am fine to rename it to dev-java/gcj. It is a gcc front-end.
No matter what. So you are right for naming.
But it provides a usable JDK in its way and usable by application
already in Portage. (see above)

> Speaking of which, I think the added compatibility layer (for javac, 
> java, etc) should be a separate package. I'm not sure if this was your 
> intention or not. Either way, it would make sense, since you would most 
> likely be able to use the same layer for different versions of gcj.

At the moment I do not see a reason to slot it. You just want the
latest version of gcj 4.1 because of enhancements and fixes.
GCJ 4.0 is missing too many features.

The reason why I want to push on gcj is because with gcj 4.1
and ecj as bytecompiler you get Azureus build and running.


Regards,
Hanno
-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] work on gcj for gentoo

[Andrew Cowie]

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

On Tue, 2006-02-21 at 10:45 -0500, Joshua Nichols wrote:
> I'm not fond of the name gcj-jdk. The ebuild Andrew made was just for 
> gcj itself, without the Java compatibility stuff, iirc. -jdk suggests 
> that it provides a usable JDK, which it doesn't as it was.

... but was hoping to get there some day.

> Speaking of which, I think the added compatibility layer (for javac, 
> java, etc) should be a separate package. I'm not sure if this was your 
> intention or not. Either way, it would make sense, since you would most 
> likely be able to use the same layer for different versions of gcj.

You guys are the devs, so packag{ing,e name} decisions are yours to make
as you see fit.

The decision would seem to be

        dev-java/gcj
        dev-java/java-gcj-compat depends on dev-java/gcj

vs

        dev-java/gcj-jdk

While I prefer the latter name, I am very sensitive to the issue that
once we call it a jdk (or rather, once java-config allows it to be
selected) we're in for a nightmare of people's expectations not matching
what is actually there...

[shit like "why isn't it magically creating a binary for me? I thought
GCJ created binaries! Bastards, rant rant rant]

... which we'll probably get either way, especially as people
misunderstand the { dev-java/gnu-classpath version vs gcj's imported
version of classpath } issue and the { what Free Java is capable of
these days } issue and the { gcj -C plus gij as JDK vs gcj -c plus gcj
(link) as native compiler } issue.

Lots of misunderstanding! Oh well. Doesn't mean we shouldn't carry on
and leverage what the Red Hat boys are up to.

AfC
Sydney


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-java] work on gcj for gentoo

[Hanno Meyer-Thurow]

On Wed, 22 Feb 2006 19:16:22 +1100
Andrew Cowie <andrew@operationaldynamics.com> wrote:

> On Tue, 2006-02-21 at 10:45 -0500, Joshua Nichols wrote:
> > I'm not fond of the name gcj-jdk. The ebuild Andrew made was just for 
> > gcj itself, without the Java compatibility stuff, iirc. -jdk suggests 
> > that it provides a usable JDK, which it doesn't as it was.
> 
> ... but was hoping to get there some day.

Some news of my overlay

I added
	* shell wrapper scripts for java{,c,doc} to reflect gij / ecj / gjdoc
	* symlinks to jar, javah, rmic (from fastjar, gcjh, grmic)
	* java-config-2 integration with java-config-1 compat
	* PDEPEND on eclipse-ecj and gjdoc

to provide a usable JDK with dev-java/gcj

I also added a Ecj Compiler Adapter and GnuRmic Rmic Adapter
to ant-{core,tasks} which need review. They seem to work.
It is simple code.

Azureus, Beanshell, eclipse-sdk, Xalan and dependencies merged
without issues. OpenOffice.org will need some tweaking for gcj / ecj.
Luckily there is a hack from Arklinux to base the work on.

My todo
	high priority
	* fix issues that pop up (OOo, ...)
	* wait for java-config-2 to get into Portage

	medium priority
	* integrate jar to native

	low priority
	* eclipse-sdk to native

---
I really dislike that java-gcj-compat.
Why? I used it. It is extra work you just do not want.

I just do not want to see it in Gentoo! ;)
---

> > Speaking of which, I think the added compatibility layer (for javac, 
> > java, etc) should be a separate package. I'm not sure if this was your 
> > intention or not. Either way, it would make sense, since you would most 
> > likely be able to use the same layer for different versions of gcj.
> 
> You guys are the devs, so packag{ing,e name} decisions are yours to make
> as you see fit.

Would be a cut and paste from dev-java/gcj then.

> While I prefer the latter name, I am very sensitive to the issue that
> once we call it a jdk (or rather, once java-config allows it to be
> selected) we're in for a nightmare of people's expectations not matching
> what is actually there...
> 
> [shit like "why isn't it magically creating a binary for me? I thought
> GCJ created binaries! Bastards, rant rant rant]

That would be the database / jar to native work as planned.
I use 'native (nativeonly)' useflag for eclipse-ecj and gjdoc already.

> ... which we'll probably get either way, especially as people
> misunderstand the { dev-java/gnu-classpath version vs gcj's imported
> version of classpath } issue and the { what Free Java is capable of
> these days } issue and the { gcj -C plus gij as JDK vs gcj -c plus gcj
> (link) as native compiler } issue.

True.

We got java{,c} for standard JDK behaviour.
I add 'native' useflag to get native code.

There will be issues, for sure.

> Lots of misunderstanding! Oh well. Doesn't mean we shouldn't carry on
> and leverage what the Red Hat boys are up to.

I set one way to go.
It just needs to be accepted or tweaked to your liking. ;)
Finally, one needs to write the code.
-> which is me
... and maybe some Java programmer
that got some extra spare time to waste?


Regards,
Hanno
-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] work on gcj for gentoo

[Andrew Cowie]

On Mon, 2006-02-27 at 23:38 +0100, Hanno Meyer-Thurow wrote:
> Finally, one needs to write the code.
> -> which is me
> ... and maybe some Java programmer
> that got some extra spare time to waste?

I don't know very many people with "time to waste" (if I was ever to
characterize my work in those terms my board would kill me), but we
certainly am interested in seeing GCJ become usable on Gentoo separately
from GCC.

We have a number of a applications which are designed to work properly
with either a JDK or with GCJ so I am happy to help you test once you
get that far along.

AfC
Sydney

-- 
Andrew Frederick Cowie
Managing Director
Operational Dynamics Consulting Pty Ltd

http://www.operationaldynamics.com/
Management Consultants specializing in strategy,
organizational architecture, procedures to survive
change, and performance hardening for the people
and systems behind the mission critical enterprise.

Worldwide:

Sydney    +61 2 9977 6866
New York  +1 646 472 5054
Toronto   +1 416 848 6072
London    +44 207 1019201

-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] work on gcj for gentoo

[Hanno Meyer-Thurow]

On Wed, 01 Mar 2006 23:30:12 +1100
Andrew Cowie <andrew@operationaldynamics.com> wrote:

> On Mon, 2006-02-27 at 23:38 +0100, Hanno Meyer-Thurow wrote:
> > Finally, one needs to write the code.
> > -> which is me
> > ... and maybe some Java programmer
> > that got some extra spare time to waste?
> 
> I don't know very many people with "time to waste" (if I was ever to
> characterize my work in those terms my board would kill me), but we
> certainly am interested in seeing GCJ become usable on Gentoo separately
> from GCC.
> 
> We have a number of a applications which are designed to work properly
> with either a JDK or with GCJ so I am happy to help you test once you
> get that far along.

Sorry if it seemed to force you or anyone to do it.
It was not meant like that.

I just ask for help on 'Ecj Compiler Adapter' and 'GnuRmic Rmic
Adapter' for ant where I already placed the Class for both.
Now there is one with Java knowledge prefered to tweak them only.
Just because I do not have the knowledge and one would do it proper.

There are more important things on my TODO list right now.
I will have a look on that somewhen if noone else does. Still,
one with Java knowledge would do it faster and cleaner.

Just if one is interested to work on it.
It would push the work forward and we
get a useable GCJ earlier.


Have fun!
Hanno
-- 
gentoo-java@gentoo.org mailing list

[RESEND] Re: [gentoo-java] work on gcj for gentoo

[Hanno Meyer-Thurow]

On Wed, 22 Feb 2006 19:16:22 +1100
Andrew Cowie <andrew@operationaldynamics.com> wrote:

> On Tue, 2006-02-21 at 10:45 -0500, Joshua Nichols wrote:
> > I'm not fond of the name gcj-jdk. The ebuild Andrew made was just for 
> > gcj itself, without the Java compatibility stuff, iirc. -jdk suggests 
> > that it provides a usable JDK, which it doesn't as it was.
> 
> ... but was hoping to get there some day.

Some news of my overlay

I added
	* shell wrapper scripts for java{,c,doc} to reflect gij / ecj / gjdoc
	* symlinks to jar, javah, rmic (from fastjar, gcjh, grmic)
	* java-config-2 integration with java-config-1 compat
	* PDEPEND on eclipse-ecj and gjdoc

to provide a usable JDK with dev-java/gcj

I also added a Ecj Compiler Adapter and GnuRmic Rmic Adapter
to ant-{core,tasks} which need review. They seem to work.
It is simple code.

Azureus, Beanshell, eclipse-sdk, Xalan and dependencies merged
without issues. OpenOffice.org will need some tweaking for gcj / ecj.
Luckily there is a hack from Arklinux to base the work on.

My todo
	high priority
	* fix issues that pop up (OOo, ...)
	* wait for java-config-2 to get into Portage

	medium priority
	* integrate jar to native

	low priority
	* eclipse-sdk to native

---
I really dislike that java-gcj-compat.
Why? I used it. It is extra work you just do not want.

I just do not want to see it in Gentoo! ;)
---

> > Speaking of which, I think the added compatibility layer (for javac, 
> > java, etc) should be a separate package. I'm not sure if this was your 
> > intention or not. Either way, it would make sense, since you would most 
> > likely be able to use the same layer for different versions of gcj.
> 
> You guys are the devs, so packag{ing,e name} decisions are yours to make
> as you see fit.

Would be a cut and paste from dev-java/gcj then.

> While I prefer the latter name, I am very sensitive to the issue that
> once we call it a jdk (or rather, once java-config allows it to be
> selected) we're in for a nightmare of people's expectations not matching
> what is actually there...
> 
> [shit like "why isn't it magically creating a binary for me? I thought
> GCJ created binaries! Bastards, rant rant rant]

That would be the database / jar to native // java to native work as planned.
I use 'native (nativeonly)' useflag for eclipse-ecj and gjdoc already.

> ... which we'll probably get either way, especially as people
> misunderstand the { dev-java/gnu-classpath version vs gcj's imported
> version of classpath } issue and the { what Free Java is capable of
> these days } issue and the { gcj -C plus gij as JDK vs gcj -c plus gcj
> (link) as native compiler } issue.

True.

We got java{,c}, et cetera, for standard JDK behaviour.
I add 'native' useflag to get native code.

There will be issues, for sure.

> Lots of misunderstanding! Oh well. Doesn't mean we shouldn't carry on
> and leverage what the Red Hat boys are up to.

I set one way to go.
It just needs to be accepted or tweaked to your liking. ;)
Finally, one needs to write the code.
	* which is me
	* ... and maybe some Java programmer that got some
	  extra spare time to waste


Regards,
Hanno
-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] work on gcj for gentoo

[Hanno Meyer-Thurow]

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

Hi list!
I got ant-core built by native ecj. I added a simple Ecj CompilerAdapter
for ant-core to use -Dbuild.compiler=ecj which seems to work. That
CompilerAdapter is a copy of Gcj CompilerAdapter plus infos from
http://sources.redhat.com/ml/rhug-rhats/2004-05/msg00002.html

Now if one Java developer could help to improve the CompilerAdapter
for Ecj I would be very happy.

Why I add another CompilerAdaper for Ecj?
I have to delete the one from ecj because of missing ant-core at that
point. I also want to use the ecj binary instead of gij / ecj.jar.

How did I get there?
I put my ecj binary to ${JAVA_HOME}/bin/ecj-native.
I add a wrapper script as ${JAVA_HOME}/bin/ecj.
Which looks like
	"ecj-native -bootclasspath /opt/gcj-jdk-4.1/share/java/libgcj-4.1.0-pre20060219.jar $@"

JAVA_HOME=/opt/gcj-jdk-4.1


My diff to ant-core is attached.
I will update my overlay soon.

Any help or pointers are welcomed!
Especially of sanitizing all this.


Another thing I came across. Something to worry about?

nb ~ # ldd /opt/gcj-jdk-4.1/lib/libgcj.so.7
	...
	libgcc_s.so.1 => /usr/lib/gcc/i686-pc-linux-gnu/4.1.0-pre20060219/libgcc_s.so.1 (0xb6a51000)
	...
nb ~ # ldd /opt/gcj-jdk-4.1/lib/libgij.so.7
	...
	libgcc_s.so.1 => /opt/gcj-jdk-4.1/lib/libgcc_s.so.1 (0xb6a4c000)
	...
nb ~ # ldd /opt/gcj-jdk-4.1/lib/lib-gnu-java-awt-peer-gtk.so.7
	...
	libgcc_s.so.1 => /usr/lib/gcc/i686-pc-linux-gnu/4.1.0-pre20060219/libgcc_s.so.1 (0xb7780000)
	...


Regards,
Hanno

[-- Attachment #2: ant-core-ecj.diff --]
[-- Type: text/x-patch, Size: 5062 bytes --]

--- build.sh.orig	2006-02-22 00:24:13.000000000 +0100
+++ build.sh	2006-02-22 00:26:46.000000000 +0100
@@ -41,5 +41,5 @@
   ANT_INSTALL="-emacs"
 fi
 
-bootstrap/bin/ant -lib lib/optional "$ANT_INSTALL" $*
+bootstrap/bin/ant -lib lib/optional -Dbuild.compiler=ecj "$ANT_INSTALL" $*
 
--- bootstrap.sh.orig	2006-02-22 17:06:18.000000000 +0100
+++ bootstrap.sh	2006-02-22 17:05:45.000000000 +0100
@@ -126,7 +126,7 @@
 
 echo ... Compiling Ant Classes
 
-"${JAVAC}" $BOOTJAVAC_OPTS -d ${CLASSDIR} ${TOOLS}/bzip2/*.java ${TOOLS}/tar/*.java ${TOOLS}/zip/*.java \
+${JAVAC} $BOOTJAVAC_OPTS -d ${CLASSDIR} ${TOOLS}/bzip2/*.java ${TOOLS}/tar/*.java ${TOOLS}/zip/*.java \
     ${TOOLS}/ant/util/regexp/RegexpMatcher.java \
     ${TOOLS}/ant/util/regexp/RegexpMatcherFactory.java \
     ${TOOLS}/ant/types/*.java \
@@ -150,7 +150,7 @@
 
 echo ... Building Ant Distribution
 
-"${JAVACMD}" -classpath "${CLASSPATH}" -Dant.home=. $ANT_OPTS org.apache.tools.ant.Main -emacs "$@" bootstrap
+"${JAVACMD}" -classpath "${CLASSPATH}" -Dbuild.compiler=ecj -Dant.home=. $ANT_OPTS org.apache.tools.ant.Main -emacs "$@" bootstrap
 ret=$?
 if [ $ret != 0 ]; then  
   echo ... Failed Building Ant Distribution !
--- src/main/org/apache/tools/ant/taskdefs/compilers/CompilerAdapterFactory.java.orig	2006-02-22 16:43:17.000000000 +0100
+++ src/main/org/apache/tools/ant/taskdefs/compilers/CompilerAdapterFactory.java	2006-02-22 16:43:41.000000000 +0100
@@ -120,6 +120,9 @@
             if (compilerType.equalsIgnoreCase("kjc")) {
                 return new Kjc();
             }
+            if (compilerType.equalsIgnoreCase("ecj")) {
+                return new Ecj();
+            }
             if (compilerType.equalsIgnoreCase("gcj")) {
                 return new Gcj();
             }
--- /dev/null	2005-12-16 14:04:54.000000000 +0100
+++ src/main/org/apache/tools/ant/taskdefs/compilers/Ecj.java	2006-02-22 16:45:18.000000000 +0100
@@ -0,0 +1,99 @@
+/*
+ * Copyright  2001-2005 The Apache Software Foundation
+ *
+ *  Licensed under the Apache License, Version 2.0 (the "License");
+ *  you may not use this file except in compliance with the License.
+ *  You may obtain a copy of the License at
+ *
+ *      http://www.apache.org/licenses/LICENSE-2.0
+ *
+ *  Unless required by applicable law or agreed to in writing, software
+ *  distributed under the License is distributed on an "AS IS" BASIS,
+ *  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ *  See the License for the specific language governing permissions and
+ *  limitations under the License.
+ *
+ */
+
+package org.apache.tools.ant.taskdefs.compilers;
+
+
+import org.apache.tools.ant.BuildException;
+import org.apache.tools.ant.Project;
+import org.apache.tools.ant.types.Commandline;
+import org.apache.tools.ant.types.Path;
+
+/**
+ * The implementation of the ecj compiler.
+ * This is primarily a cut-and-paste from the jikes.
+ *
+ * @since Ant 1.4
+ */
+public class Ecj extends DefaultCompilerAdapter {
+
+    /**
+     * Performs a compile using the ecj compiler.
+     */
+    public boolean execute() throws BuildException {
+        Commandline cmd;
+        attributes.log("Using ecj compiler", Project.MSG_VERBOSE);
+        cmd = setupECJCommand();
+
+        int firstFileName = cmd.size();
+        logAndAddFilesToCompile(cmd);
+
+        return
+            executeExternalCompile(cmd.getCommandline(), firstFileName) == 0;
+    }
+
+    protected Commandline setupECJCommand() {
+        Commandline cmd = new Commandline();
+        Path classpath = new Path(project);
+
+        // ecj doesn't support bootclasspath dir (-bootclasspath)
+        // so we'll emulate it for compatibility and convenience.
+        if (bootclasspath != null) {
+            classpath.append(bootclasspath);
+        }
+
+        // ecj doesn't support an extension dir (-extdir)
+        // so we'll emulate it for compatibility and convenience.
+        classpath.addExtdirs(extdirs);
+
+        classpath.append(getCompileClasspath());
+
+        // Gcj has no option for source-path so we
+        // will add it to classpath.
+        if (compileSourcepath != null) {
+            classpath.append(compileSourcepath);
+        } else {
+            classpath.append(src);
+        }
+
+        cmd.setExecutable("ecj");
+
+        if (destDir != null) {
+            cmd.createArgument().setValue("-d");
+            cmd.createArgument().setFile(destDir);
+
+            if (!destDir.exists() && !destDir.mkdirs()) {
+                throw new BuildException("Can't make output directories. "
+                                         + "Maybe permission is wrong. ");
+            }
+        }
+
+        cmd.createArgument().setValue("-classpath");
+        cmd.createArgument().setPath(classpath);
+
+        if (encoding != null) {
+            cmd.createArgument().setValue("-encoding " + encoding);
+        }
+        if (debug) {
+            cmd.createArgument().setValue("-g");
+        }
+
+        addCurrentCompilerArgs(cmd);
+
+        return cmd;
+    }
+}

Re: [gentoo-java] work on gcj for gentoo

[Andrew Cowie]

On Tue, 2006-02-21 at 16:04 +0100, Hanno Meyer-Thurow wrote:
> gcj for Gentoo

Today on the gcj mailing list Bryce McKinlay noted,

        "the other recent change on the trunk that effects build time
        was the change to perform a bootstrap build by default.
        
        In addition to "--disable-bootstrap", you can also use
        "--disable-static" to further reduce build time. This stops a
        statically-linked copy of libgcj and other runtime libraries
        from being built - otherwise everything gets built twice."
        
That should save some build time and installed image space in the
monster that results from the dev-java/gcj-jdk ebuild!

AfC
Sydney

-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] work on gcj for gentoo

[Hanno Meyer-Thurow]

On Thu, 23 Feb 2006 13:09:52 +1100
Andrew Cowie <andrew@operationaldynamics.com> wrote:

> Today on the gcj mailing list Bryce McKinlay noted,
> 
>         "the other recent change on the trunk that effects build time
>         was the change to perform a bootstrap build by default.
>         
>         In addition to "--disable-bootstrap", you can also use
>         "--disable-static" to further reduce build time. This stops a
>         statically-linked copy of libgcj and other runtime libraries
>         from being built - otherwise everything gets built twice."

Thanks Andrew!

---
My next step:

	After 'make install' I will delete useless files and I will move
header files to fit into include/. If you have another better idea
please tell me.


Regards,
Hanno
-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] work on gcj for gentoo

[Hanno Meyer-Thurow]

On Thu, 23 Feb 2006 12:25:08 +0100
Hanno Meyer-Thurow <h.mth@web.de> wrote:

> My next step:
> 
> 	After 'make install' I will delete useless files and I will move
> header files to fit into include/. If you have another better idea
> please tell me.

I added these configure switches:
        --mandir=/opt/${PN}-${SLOT}/share/man \
        --infodir=/opt/${PN}-${SLOT}/share/info \
        --with-gxx-include-dir=/opt/${PN}-${SLOT}/include \

What I see is that these can be disabled.
	libmudflap, libobjc, libssp

... that unrelated binaries like gcc, g++, etc. can be deleted.

I also copy some headers to include/ to have them in one place
for applications including them. No idea if that is needed.

I still built them and did not delete that binaries because of an
issue I hit with native build of gjdoc:

/bin/sh ./libtool --tag=GCJ --mode=link gcj --classpath=. -fassume-compiled -I./src -I. -I/usr/share/antlr/lib/antlr.jar -I. -g -O2  -Wl,-O1 -o gjdoc --main=gnu.classpath.tools.gjdoc.Main
-Dgnu.gcj.runtime.VMClassLoader.library_control=never  -l-com-sun-javadoc -l-com-sun-tools-doclets-Taglet -l-gnu-classpath-tools-gjdoc antlr.so
gcj --classpath=. -fassume-compiled -I./src -I. -I/usr/share/antlr/lib/antlr.jar -I. -g -O2 -Wl,-O1 -o .libs/gjdoc --main=gnu.classpath.tools.gjdoc.Main -Dgnu.gcj.runtime.VMClassLoader.library_control=never antlr.so  /var/tmp/portage/gjdoc-0.7.7/work/gjdoc-0.7.7/.libs/lib-com-sun-javadoc.so /var/tmp/portage/gjdoc-0.7.7/work/gjdoc-0.7.7/.libs/lib-com-sun-tools-doclets-Taglet.so /var/tmp/portage/gjdoc-0.7.7/work/gjdoc-0.7.7/.libs/lib-gnu-classpath-tools-gjdoc.so
/var/tmp/portage/gjdoc-0.7.7/work/gjdoc-0.7.7/.libs/lib-gnu-classpath-tools-gjdoc.so: undefined reference to `java::lang::Class::getSuperclass()'
collect2: ld returned 1 exit status
make[2]: *** [gjdoc] Fehler 1


Any concerns?
Any ideas why it could fail?


Regards,
Hanno
-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] work on gcj for gentoo

[Hanno Meyer-Thurow]

On Fri, 24 Feb 2006 18:26:29 +0100
Hanno Meyer-Thurow <h.mth@web.de> wrote:

> /bin/sh ./libtool --tag=GCJ --mode=link gcj --classpath=. -fassume-compiled -I./src -I. -I/usr/share/antlr/lib/antlr.jar -I. -g -O2  -Wl,-O1 -o gjdoc --main=gnu.classpath.tools.gjdoc.Main
> -Dgnu.gcj.runtime.VMClassLoader.library_control=never  -l-com-sun-javadoc -l-com-sun-tools-doclets-Taglet -l-gnu-classpath-tools-gjdoc antlr.so
> gcj --classpath=. -fassume-compiled -I./src -I. -I/usr/share/antlr/lib/antlr.jar -I. -g -O2 -Wl,-O1 -o .libs/gjdoc --main=gnu.classpath.tools.gjdoc.Main -Dgnu.gcj.runtime.VMClassLoader.library_control=never antlr.so  /var/tmp/portage/gjdoc-0.7.7/work/gjdoc-0.7.7/.libs/lib-com-sun-javadoc.so /var/tmp/portage/gjdoc-0.7.7/work/gjdoc-0.7.7/.libs/lib-com-sun-tools-doclets-Taglet.so /var/tmp/portage/gjdoc-0.7.7/work/gjdoc-0.7.7/.libs/lib-gnu-classpath-tools-gjdoc.so
> /var/tmp/portage/gjdoc-0.7.7/work/gjdoc-0.7.7/.libs/lib-gnu-classpath-tools-gjdoc.so: undefined reference to `java::lang::Class::getSuperclass()'
> collect2: ld returned 1 exit status
> make[2]: *** [gjdoc] Fehler 1

AFAIS it is fixed by this for x86/glibc usage, at least here:
(There is much more from toolchain.eclass that we want.)

...
    strip-flags

    ${S}/configure ${conf} \
        || die "configure failed!"

    make \
        BOOT_CFLAGS="${CFLAGS}" \
        LDFLAGS="-Wl,-O1" \
        LIBPATH="/opt/${PN}-${SLOT}/lib" \
        STAGE1_CFLAGS="-O" \
        profiledbootstrap \
        || die "make failed!"
...

---
Btw, I changed this to take effect now:

-	--with-languages=java
+	--enable-languages=c,c++,java

This stops objc to build.
We want language c for bootstrapping stuff.
Fixes that error?!

---
lib/libgcj.so.7.0.0 still links to libgcc_s.so.1 from system gcc.

I do not like to see that. But, however, the more we copy
from toolchain.eclass it may change.


Regards,
Hanno
-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] work on gcj for gentoo

[Hanno Meyer-Thurow]

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

On Tue, 21 Feb 2006 16:04:25 +0100
Hanno Meyer-Thurow <h.mth@web.de> wrote:

> Hi list!
> I would like to work on gcj for Gentoo.

I did a patch for Java eclasses to create native libraries from jar
files dependend on the 'native' useflag. Patch is attached. This is
for reference, questions and ideas.

I added 'use native && java-pkg_cachejar' to java-pkg_dojar function.
I only process jar files in '${D}${JAVA_PKG_JARDEST}'.
I check the existance of native library not to cache same jar twice.


What is the best place to add 'java-pkg_cachejar'?

Any suggestions not to miss a jar file?
It seems to be possible to install to a alternative place, so ...

How do I collect jar files of the package in pkg_postinst process?


Thanks in advance for help!

> Regards,
> Hanno

[-- Attachment #2: cachejar.patch --]
[-- Type: text/x-patch, Size: 3536 bytes --]

--- portage-migration/eclass/java-pkg-2.eclass.orig	2006-02-28 09:14:57.000000000 +0100
+++ portage-migration/eclass/java-pkg-2.eclass	2006-02-28 11:17:56.000000000 +0100
@@ -34,6 +34,8 @@
 
 EXPORT_FUNCTIONS pkg_setup
 
+IUSE="${IUSE} native"
+
 # ------------------------------------------------------------------------------
 # @eclass-pkg_setup
 #
@@ -79,6 +81,7 @@
 
 pre_pkg_postinst() {
 	java-pkg-2_pkg_setup
+	java-pkg_postinst
 }
 
 # ------------------------------------------------------------------------------
--- portage-migration/eclass/java-utils-2.eclass.orig	2006-02-28 09:15:04.000000000 +0100
+++ portage-migration/eclass/java-utils-2.eclass	2006-02-28 11:43:04.000000000 +0100
@@ -183,6 +183,7 @@
 	done
 
 	java-pkg_do_write_
+	use native && java-pkg_cachejar
 }
 
 
@@ -1552,6 +1553,91 @@
 }
 
 # ------------------------------------------------------------------------------
+# @internal-function java-pkg_cachejar
+#
+# Create native library from jar
+# Stolen from OpenOffice.org
+# ------------------------------------------------------------------------------
+java-pkg_cachejar() {
+	if [[ ! "$(java-pkg_get-current-vm)" =~ "gcj" ]] ; then
+		ewarn "Your current Java VM is not gcj."
+		ewarn "You still try to build native code."
+		ewarn "Either set your Java VM to gcj"
+		ewarn "... or unset 'native' useflag."
+		return
+	fi
+
+	java-pkg_init_paths_
+
+	local linker="gcj -shared -fPIC -Wl,-Bsymbolic -O2 -findirect-dispatch -fjni -o"
+
+	einfo "Create native from jar ..."
+
+	local jar to
+	for jar in ${D}${JAVA_PKG_JARDEST}/*.jar
+	do
+		# .../lib`basename ${jar}`.so
+		# Linker use '-L... -l<prog>.jar' for gcj native binary
+		to="$(dirname ${jar})/lib$(basename ${jar}).so"
+
+		if [[ ! -e ${to} ]] ; then
+			einfo "${jar} -> ${to}"
+			${linker} ${to} ${jar}
+		fi
+	done
+}
+
+# ------------------------------------------------------------------------------
+# @internal-function java-pkg_regcachejar
+#
+# Create native library from jar
+# Stolen from OpenOffice.org
+# ------------------------------------------------------------------------------
+java-pkg_reg-cachejar() {
+	if [[ ! "$(java-pkg_get-current-vm)" =~ "gcj" ]] ; then
+		ewarn "Your current Java VM is not gcj."
+		ewarn "You still try to build native code."
+		ewarn "Either set your Java VM to gcj"
+		ewarn "... or unset 'native' useflag."
+		return
+	fi
+
+	java-pkg_init_paths_
+
+	local db_tool="gcj-dbtool"
+	local gcj_db="/usr/share/java/classmap.gcjdb"
+
+	# Create new database?
+	if [[ ! -e ${gcj_db} ]] ; then
+		[[ ! -d /usr/share/java/ ]] && mkdir -p /usr/share/java/
+		${db_tool} -n ${gcj_db}
+	fi
+
+	einfo "Register jar to native (gcj) link in database (${gcj_db}) ..."
+
+	local jar to
+	# Where do I get the jar files installed now from?
+	for jar in ${JAVA_PKG_JARDEST}/*.jar
+	do
+		# .../lib`basename ${jar}`.so
+		# Linker use '-L... -l<prog>.jar' for gcj native binary
+		to="$(dirname ${jar})/lib$(basename ${jar}).so"
+
+		einfo "${jar} -> ${to}"
+		${db_tool} -a ${gcj_db} ${jar} ${to}
+	done
+}
+
+# ------------------------------------------------------------------------------
+# @internal-function java-pkg_postinst
+#
+# Do post-install stuff
+# ------------------------------------------------------------------------------
+java-pkg_postinst() {
+	use native && java-pkg_reg-cachejar
+}
+
+# ------------------------------------------------------------------------------
 # @internal-function java-pkg_die
 #
 # Enhanced die for Java packages, which displays some information that may be

Re: [gentoo-java] work on gcj for gentoo

[Hanno Meyer-Thurow]

> > I would like to work on gcj for Gentoo.
> 
> I did a patch for Java eclasses to create native libraries from jar

http://geki.ath.cx/hacks/cachejar.patch

There you find the latest version of my patch.
Thank you, Joshua, for your help!


Regards,
Hanno
-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] work on gcj for gentoo

[Hanno Meyer-Thurow]

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

On Tue, 28 Feb 2006 11:25:15 +0100
Hanno Meyer-Thurow <h.mth@web.de> wrote:

> On Tue, 21 Feb 2006 16:04:25 +0100
> Hanno Meyer-Thurow <h.mth@web.de> wrote:
> 
> > Hi list!
> > I would like to work on gcj for Gentoo.
> 
> I did a patch for Java eclasses to create native libraries from jar

I did a script to (re-)build a .gcjdb file with all or selected Java
packages which I get from 'java-config --classpath=pkg-list'.
(script is attached)

Why?

1.	I do not know the behaviour of a re-emerged package.
Will that dbtool update its database or doubling/breaking something?

2.	(re-)create from scratch

3.	For the users convenience to create their applications specific
database instead of one big database.


With that a question raises regarding to the eclass patch.
Would it be ok to just recreate the database from scratch
on each package being merged?

It would take no time to recreate.


Regards,
Hanno

[-- Attachment #2: rebuild-classmap-db --]
[-- Type: application/octet-stream, Size: 1760 bytes --]

#!/bin/sh

# set defaults
JAVA_PKG_DB_TOOL=${JAVA_PKG_DB_TOOL:="${JAVA_HOME}/bin/gcj-dbtool"}
JAVA_PKG_CLASSMAP=${JAVA_PKG_CLASSMAP:="/usr/share/java/classmap.gcjdb"}

# functions
die_hard() {
	echo "ERROR: ${@}"
	exit 1
}

show_help() {
	echo "To rebuild your database run:"
	echo "	'${0} <database file> [ <packages> ]'"
	echo
	echo
	echo " database file:		/path/to/file.gcjdb"
	echo
	echo " packages:		comma-separated list of packages from 'java-config -l'"
	echo
	echo
	echo "To recreate the default database with all packages being checked execute:"
	echo "	'${0} ${JAVA_PKG_CLASSMAP}'"
}

check_pkgs() {
	local pkg pkgs
	for pkg in $(java-config -l | cut -d] -f1 | cut -c2-)
	do
		pkgs="${pkg} ${pkgs}"
	done
	check_classpath "${pkgs}"
}

check_classpath() {
	echo "check package(s) (${@})"
	local jar to
	classpath="$(java-config --classpath=${@})"
	for jar in ${classpath//:/ }
	do
		to="$(dirname ${jar})/lib$(basename ${jar}).so"
		if [[ ( -f ${jar} ) && ( ".jar" == "${jar: -4:4}" ) && ( -f ${to} ) ]] ; then
			echo "register: ${to}"
			${JAVA_PKG_DB_TOOL} -a ${DB_FILE} ${jar} ${to} \
				|| die_hard "failed to register jar file"
		fi
	done
}

# errors
if [[ ( ${#} -lt 1 ) || ( ${#} -ge 3 ) ]] ; then
	show_help
	exit 1
fi

if [[ ! -x ${JAVA_PKG_DB_TOOL} ]] ; then
	echo "Java native tools unusable!"
	exit 1
fi

DB_FILE="${1}"

# we may want to create one from scratch
#if [[ ! -f ${DB_FILE} ]] ; then
#	echo "Given argument is no regular file?!"
#	exit 1
#fi

if [ ".gcjdb" != "${DB_FILE: -6:6}" ] ; then
	echo "Given file has unknown format?!"
	exit 1
fi

# start
echo "recreate database (${DB_FILE})"
rm -f ${DB_FILE}
${JAVA_PKG_DB_TOOL} -n ${DB_FILE}

if [[ -n "${2}" ]] ; then
	check_classpath "${2}"
else
	check_pkgs
fi

echo "... done!"

Re: [gentoo-java] work on gcj for gentoo

[Hanno Meyer-Thurow]

On Tue, 21 Feb 2006 16:04:25 +0100
Hanno Meyer-Thurow <h.mth@web.de> wrote:

> Hi list!
> I would like to work on gcj for Gentoo.

I splitted dev-java/gcj to dev-java/gcj-jdk for Java wrappers.
I dropped my ecj compiler adapter and gnu rmic adapter.
I use java-gcj-compat in that gcj-jdk package to get a tools.jar.
In that jar is only a wrapper for rmic. As ant compiler I use a
gcj-javac compiler-config that sets -Dbuild.compiler=extJava
which you can set in /etc/java-config-2/build/compilers.conf.
And if my evil lib/libjawt.so -> lib/libgcjawt.so link does the trick
I can drop my gcjawt hacks.

Why I do not use tools.jar for default ant compiler?
I would like, hell, I would like...
....have a look at it and fix it. :)
Thanks!


So far...

Regards,
Hanno
-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] work on gcj for gentoo

[Hanno Meyer-Thurow]

On Sat, 11 Mar 2006 21:51:03 +0100
Hanno Meyer-Thurow <h.mth@web.de> wrote:

> I splitted dev-java/gcj to dev-java/gcj-jdk for Java wrappers.

Some annoying issues solved more or less.

> I dropped my ecj compiler adapter and gnu rmic adapter.

I readded a native ecj compiler adapter. I copied the extJavac
one where no switches need to be set. Ant does the magic.

> I use java-gcj-compat in that gcj-jdk package to get a tools.jar.
> In that jar is only a wrapper for rmic. As ant compiler I use a
> gcj-javac compiler-config that sets -Dbuild.compiler=extJava
> which you can set in /etc/java-config-2/build/compilers.conf.

I use again my native ecj binary from eclipse-ecj

> And if my evil lib/libjawt.so -> lib/libgcjawt.so link does the trick
> I can drop my gcjawt hacks.

It seems to work.

> Why I do not use tools.jar for default ant compiler?
> I would like, hell, I would like...
> ....have a look at it and fix it. :)
> Thanks!

I have no clue how to use it properly.
At least dev-java/gcj-jdk uses java-gcj-compat.
So you guys can fiddle with it.
I just try to ignore it as much as possible. ;)


> So far...

Important changes in detail:
---
eclipse-ecj:
	* add gcj useflag,
	  drop java-nativeonly, java-native-bin useflags
	* gcj useflag: build ecj.jar and native binary

gjdoc:
	* add gcj useflag
	* drop java-native-bin useflag
	* gcj useflag: build native binary

gcj-jdk:
	* use java-gcj-compat
	* drop com.sun...Main
	  (ecj wrapper / it is just troublesome)
	* use rmic wrapper
	  (as Java code in tools.jar, ant recognizes it)
	  -> it fails because of grmic's classpath issue?!

ant-core:
	* add nativeEcj Compiler Adapter
	  (a copy of extJavac Compiler Adapter, ant does the magic)
	* gcj useflag: build with native ecj

swt:
	* drop gcjawt hack

eclipse-sdk:
	* forgot to drop the hack, soon...

I forgot to fix some DEPENDs and whatever.
Will be fixed ...

My gcj overlay is here
http://geki.ath.cx/hacks/gcj-overlay-2.tar.bz2

There are some patches for gentoo-java-experimental overlay
to cut down my overlay for gcj.
http://geki.ath.cx/hacks/

There are patches for: azureus, jessie and swt
I would like to see bcprov bumped to 1.31.
However, ...


> Regards,
> Hanno
-- 
gentoo-java@gentoo.org mailing list