Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 21477 - support for gcj as a JDK
Summary: support for gcj as a JDK
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Development (show other bugs)
Hardware: All Linux
: Lowest enhancement with 1 vote (vote)
Assignee: Java team
URL: http://overlays.gentoo.org/proj/java/...
Whiteboard:
Keywords:
Depends on: 196080 197354 197923
Blocks: 31468
  Show dependency tree
 
Reported: 2003-05-22 08:08 UTC by Bapt
Modified: 2011-01-17 10:29 UTC (History)
16 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Re-worked gcj-jdk ebuild (gcj-jdk-4.3.3.ebuild,52 bytes, text/plain)
2009-02-09 15:33 UTC, Steven Newbury
Details
Re-worked gcj-jdk ebuild (hopefully it uploads this time) (gcj-jdk-4.3.3.ebuild,4.36 KB, text/plain)
2009-02-09 15:36 UTC, Steven Newbury
Details
New gcj-jdk.env source file for re-worked ebuild (gcj-jdk.env,593 bytes, text/plain)
2009-02-09 15:39 UTC, Steven Newbury
Details
updated rebuild-classmap-db (rebuild-classmap-db,2.78 KB, text/plain)
2009-02-09 15:40 UTC, Steven Newbury
Details
Patch against current java-utils-2.eclass (gcj-java-utils-2.patch,11.78 KB, patch)
2009-02-09 16:10 UTC, Steven Newbury
Details | Diff
New gcj-jdk ebuild (Fixed multislot bug and cleaned up slightly) (gcj-jdk-4.3.3.ebuild,4.44 KB, text/plain)
2009-02-09 17:40 UTC, Steven Newbury
Details
gcj-jdk.env for new ebuild in previous attachment (gcj-jdk.env,611 bytes, text/plain)
2009-02-09 17:43 UTC, Steven Newbury
Details
gcj-jdk environment source file (gcj-jdk.env.in,624 bytes, text/plain)
2009-02-12 02:30 UTC, Steven Newbury
Details
rebuild-classmap-db script ".in" source (rebuild-classmap-db.in,2.77 KB, text/plain)
2009-02-12 03:40 UTC, Steven Newbury
Details
New gcj-jdk ebuild with lots of bugs fixed and made more consistent (gcj-jdk-4.3.3.ebuild,5.14 KB, text/plain)
2009-02-12 03:58 UTC, Steven Newbury
Details
java wrapper needs to point to correct classmap db (java.in,188 bytes, text/plain)
2009-02-12 04:00 UTC, Steven Newbury
Details
Patch against portage java-utils-2.eclass to fully support gcj-jdk and native java packages (java-utils-2.eclass.patch,13.95 KB, patch)
2009-02-12 04:05 UTC, Steven Newbury
Details | Diff
java-pkg-2.eclass patch (java-pkg-2.eclass.patch,1.46 KB, patch)
2009-02-12 04:06 UTC, Steven Newbury
Details | Diff
java-pkg-opt-2.eclass patch (java-pkg-opt-2.eclass.patch,896 bytes, patch)
2009-02-12 04:07 UTC, Steven Newbury
Details | Diff
Patch against portage java-utils-2.eclass to fully support gcj-jdk and native java packages (java-utils-2.eclass.patch,14.14 KB, patch)
2009-02-12 12:57 UTC, Steven Newbury
Details | Diff
Even better gcj-jdk ebuild (gcj-jdk-4.3.3.ebuild,5.56 KB, text/plain)
2009-02-12 14:29 UTC, Steven Newbury
Details
java-utils-2.class patch with improved rpath handling (java-utils-2.eclass.patch,14.38 KB, text/plain)
2009-02-12 14:31 UTC, Steven Newbury
Details
eclipse-ecj ebuild utilising the improved native machinery (eclipse-ecj-3.4.1.ebuild,2.83 KB, text/plain)
2009-02-12 14:39 UTC, Steven Newbury
Details
gcj-jdk.env.in: fix JAVA_HOME bug (gcj-jdk.env.in,560 bytes, text/plain)
2009-02-12 15:10 UTC, Steven Newbury
Details
gcj-jdk ebuild: fix JAVA_HOME bug (gcj-jdk-4.3.3.ebuild,5.50 KB, text/plain)
2009-02-12 15:13 UTC, Steven Newbury
Details
gcj-jdk ebuild: added symlinks for all libgcj* libs (gcj-jdk-4.3.3.ebuild,5.54 KB, text/plain)
2009-02-12 15:46 UTC, Steven Newbury
Details
java-utils-2.eclass patch fix yet another bug (java-utils-2.eclass.patch,14.41 KB, patch)
2009-02-12 17:39 UTC, Steven Newbury
Details | Diff
java-pkg-2.eclass patch (previous version somehow lost a function) (java-pkg-2.eclass.patch,792 bytes, patch)
2009-02-12 17:53 UTC, Steven Newbury
Details | Diff
gcj-jdk ebuild (gcj-jdk-4.3.3.ebuild,5.63 KB, text/plain)
2009-02-13 01:40 UTC, Steven Newbury
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Bapt 2003-05-22 08:08:36 UTC
Is it possible to add gij/gcj in java-config in order to be able to use libgcj
as a default java sdk and gij for interpreter in the same wey we do for all
other java components
Comment 1 Martin Schlemmer (RETIRED) gentoo-dev 2003-11-09 15:33:26 UTC
Possibly - have a look at the following from Mandrake:

gcc-java:
---------
http://cvs.mandrakesoft.com/cgi-bin/cvsweb.cgi/~checkout~/SPECS/gcc/gcc31-java?rev=1.2&content-type=text/plain

gcc-javac:
----------
http://cvs.mandrakesoft.com/cgi-bin/cvsweb.cgi/~checkout~/SPECS/gcc/gcc31-javac?rev=1.1&content-type=text/plain


I am not sure on how good it will work though.
Comment 2 Adrian Almenar 2003-11-09 19:04:27 UTC
ok, perfect, but Azarah who will handle to install those files if they get
added ? a new package called gcc-java ?, gcc ?, java-config ?

I think that gcc should install them, like Java VM's install the java-env
files. (See for an example of this dev-java/sun-jdk/files/sun-jdk-1.4.2.02)
and install inside, lets call /opt/gcc-${VERSION} the files needed like java
and javac (Shell Scripts) to have it with some kind of consistency with the
other VM's.

What do you think of this ?
Comment 3 Martin Schlemmer (RETIRED) gentoo-dev 2003-11-16 10:06:34 UTC
Do they actually work for you as expected ?

As for in /opt ... I do not think I like this - Is java-config not
flexible enouth to allow a different setup.  Also, As I am not really
a java-junky, what needs to be done in the ebuild to make java-config
work (setup env, etc) ?
Comment 4 Adrian Almenar 2003-11-16 12:18:08 UTC
Yes java-config is enought flexible to do that, it was just an example not
a definitive proposal =).

Ill try to try those scripts from mandrake and adapt them for gentoo, then
ill advice you how did they worked.

Only you need to do this:
inherit java
set_java_env ${FILESDIR}/${VMHANDLE}

where VMHANDLE is VMHANDLE=${PN}-${PV}

Also as an example look at this file (
http://www.gentoo.org/cgi-bin/viewcvs.cgi/dev-java/sun-jdk/files/sun-jdk-1.4.2.02?rev=1.1&content-type=text/vnd.viewcvs-markup
), something similar will be needed for gcc/gcj to set the CLASSPATH and
enviroment (But be careful we cant install the scripts that will act as a
wrapper for gcj on in a place available to the classpath. They should be
installed in another place of the file system java-config modifies the PATH
and adds the dir where the wrappers are located, some similar like ccache,
distcc  config is handled.)

ill try to post here the file needed for java-config and the scripts so you
can add them to the gcc ebuild.
Comment 5 Ernst Sjöstrand 2004-03-22 15:04:22 UTC
http://freshmeat.net/projects/jdkgcj/

Have a look at this..
Comment 6 Paper 2004-09-22 08:02:17 UTC
Any news about this "bug"?
Comment 7 Ernst Sjöstrand 2005-05-28 15:56:51 UTC
Most distros seem to use
http://sourceware.mirrors.tds.net/pub/sourceware.org/rhug/java-gcj-compat/
Comment 8 Rohan McGovern 2005-06-16 20:11:02 UTC
I've put together an ebuild for java-gcj-compat which allows gcj to be selected  
with java-config.  It's pretty hacky, but it seems to work OK.  Unfortunately  
there doesn't seem to be much in portage which I can compile with gcj 3.4.4, so  
it's a bit hard to test :-(  I did successfully compile qtjava and kdejava, but  
most other java apps require ant-core, which I can't get to compile yet.  
  
The ebuild is at http://everest.fit.qut.edu.au/~n4722418/gentoo/ ; also get the  
java-gcj-compat-1.0.4 file and put it in the files dir.  
  
Pity no-one seems interested in this bug :-(  It'd be nice if someone with gcc 
4 would test it. 
 
Comment 9 Xake 2005-07-21 14:38:46 UTC
ebuild above does not work with GCC4 currently.

# emerge java-gcj-compat -v
Calculating dependencies ...done!
>>> emerge (1 of 1) dev-java/java-gcj-compat-1.0.4 to /
>>> md5 files   ;-) java-gcj-compat-1.0.4.ebuild
>>> md5 files   ;-) files/java-gcj-compat-1.0.4
>>> md5 files   ;-) files/digest-java-gcj-compat-1.0.4
>>> md5 src_uri ;-) java-gcj-compat-1.0.4.tar.gz
which: no gcj-jar in
(/usr/lib/ccache/bin:/usr/lib/distcc/bin:/sbin:/usr/sbin:/usr/lib/portage/bin:/bin:/usr/bin:/opt/bin:/usr/i686-pc-linux-gnu/gcc-bin/4.0.1:/usr/i686-pc-linux-gnu/gcc-bin/4.0.0:/usr/i386-pc-linux-gnu/gcc-bin/3.3:/opt/blackdown-jdk-1.4.2.02/bin:/opt/blackdown-jdk-1.4.2.02/jre/bin)
 * Could not find one of gcj, gij or gcj-jar!
 * Please re-merge sys-devel/gcc with the java USE flag.

!!! ERROR: dev-java/java-gcj-compat-1.0.4 failed.
!!! Function pkg_setup, Line 37, Exitcode 0
!!! Exiting due to failure finding gcj...
!!! If you need support, post the topmost build error, NOT this status message.

# emerge gcc -pv

These are the packages that I would merge, in order:

Calculating dependencies ...done!
[ebuild   R   ] sys-devel/gcc-4.0.1  (-altivec) -bootstrap -boundschecking
-build +fortran +gcj +gtk -hardened -ip28 (-multilib) -multislot (-n32) (-n64)
+nls -nocxx -nopie -objc -static 0 kB
Comment 10 Hanno Zysik (geki) 2005-07-26 14:50:43 UTC
I finally got the problem that OOo2 compiled with gcj4 misses a "Java SDK
environment". I did some more hacks in Rohan McGovern's java-gcj-compat ebuild.
Also bumped to version 1.0.31.

Get bzip'ed overlay here.
http://geki.ath.cx/OOo/java-gcj-compat-4.0.1.tar.bz2
Get filelist after merge here.
http://geki.ath.cx/OOo/java-gcj-compat-files

Version is chosen to stay in sync with gcc/gcj dependency and for ebuild
specifics, like deep linking with gcc and naming. Having it named
java-1.4.2-gcj-1.4.2.0 is just wrong for me. But have a look for yourself.

java-config yells at javadoc being not there. Minor issue for me I hope. I will
see with OOo2. What binary of gcj is for that, if any?
Comment 11 Hanno Zysik (geki) 2005-07-26 15:28:44 UTC
javadoc is necessary. I was too optimistic. Well, I did not get the binary
Comment 12 Hanno Zysik (geki) 2005-07-26 15:28:44 UTC
javadoc is necessary. I was too optimistic. Well, I did not get the binary
»gjdoc« which is gcj's javadoc. Any useflag I missed for it to be build?
Comment 13 Rohan McGovern 2005-07-26 16:51:19 UTC
Hmm... gjdoc doesn't actually appear to be a part of gcj.  Looks like it is a  
part of the GNU Classpath subprojects  
( http://www.gnu.org/software/classpath/cp-tools/ ).  Also, looks like someone  
is (or at least was at some point) working on an ebuild for it -  
http://gentooexperimental.org/svn/java/gentoo-java-experimental/dev-java/gjdoc/ . 
 
This is good stuff :-) 
Comment 14 Hanno Zysik (geki) 2005-07-27 01:46:02 UTC
One error in my ebuild.
- gcc-config is used to determine gcc paths

Which is wrong because running gcc can be a different one as java-gcj-compat is
used for.


Example

installed gccs:
gcc-3.4.4 gcc-4.0.1

running gcc: gcc-3.4.4

emerge of java-gcj-compat links to gcc-3.4.4 paths. will fix tonight.
Comment 15 Hanno Zysik (geki) 2005-07-27 11:16:18 UTC
I hopefully fixed java-gcj-compat.

gjdoc as javadoc for gcj's Java SDK environment.
/var/www/geki/htdocs/OOo/gjdoc-0.7.5.tar.bz2

Set Java SDK from SUN, Blackdown, IBM or whatever SDK you use but GCJ's one with
`java-config -S`.

gjdoc fails to compile, anyone any ideas? Using gcj-4.0.1 from portage.

 gcj --classpath=. -fassume-compiled -I./src -I.
-I/usr/share/antlr/lib/antlr.jar -I. -g -O2 -MT
src/gnu/classpath/tools/gjdoc/Debug.lo -MD -MP -MF
src/gnu/classpath/tools/gjdoc/.deps/Debug.Tpo -c
src/gnu/classpath/tools/gjdoc/Debug.java  -fPIC -o
src/gnu/classpath/tools/gjdoc/.libs/Debug.o
if /bin/sh ./libtool --tag=GCJ --mode=compile gcj --classpath=.
-fassume-compiled -I./src -I. -I/usr/share/antlr/lib/antlr.jar -I. -g -O2 -MT
src/gnu/classpath/tools/gjdoc/DocImpl.lo -MD -MP -MF
"src/gnu/classpath/tools/gjdoc/.deps/DocImpl.Tpo" -c -o
src/gnu/classpath/tools/gjdoc/DocImpl.lo `test -f
'src/gnu/classpath/tools/gjdoc/DocImpl.java' || echo
'./'`src/gnu/classpath/tools/gjdoc/DocImpl.java; \
then mv -f "src/gnu/classpath/tools/gjdoc/.deps/DocImpl.Tpo"
"src/gnu/classpath/tools/gjdoc/.deps/DocImpl.Plo"; else rm -f
"src/gnu/classpath/tools/gjdoc/.deps/DocImpl.Tpo"; exit 1; fi
 gcj --classpath=. -fassume-compiled -I./src -I.
-I/usr/share/antlr/lib/antlr.jar -I. -g -O2 -MT
src/gnu/classpath/tools/gjdoc/DirectoryTree.lo -MD -MP -MF
src/gnu/classpath/tools/gjdoc/.deps/DirectoryTree.Tpo -c
src/gnu/classpath/tools/gjdoc/DirectoryTree.java  -fPIC -o
src/gnu/classpath/tools/gjdoc/.libs/DirectoryTree.o
if /bin/sh ./libtool --tag=GCJ --mode=compile gcj --classpath=.
-fassume-compiled -I./src -I. -I/usr/share/antlr/lib/antlr.jar -I. -g -O2 -MT
src/gnu/classpath/tools/gjdoc/ErrorReporter.lo -MD -MP -MF
"src/gnu/classpath/tools/gjdoc/.deps/ErrorReporter.Tpo" -c -o
src/gnu/classpath/tools/gjdoc/ErrorReporter.lo `test -f
'src/gnu/classpath/tools/gjdoc/ErrorReporter.java' || echo
'./'`src/gnu/classpath/tools/gjdoc/ErrorReporter.java; \
then mv -f "src/gnu/classpath/tools/gjdoc/.deps/ErrorReporter.Tpo"
"src/gnu/classpath/tools/gjdoc/.deps/ErrorReporter.Plo"; else rm -f
"src/gnu/classpath/tools/gjdoc/.deps/ErrorReporter.Tpo"; exit 1; fi
 gcj --classpath=. -fassume-compiled -I./src -I.
-I/usr/share/antlr/lib/antlr.jar -I. -g -O2 -MT
src/gnu/classpath/tools/gjdoc/DocImpl.lo -MD -MP -MF
src/gnu/classpath/tools/gjdoc/.deps/DocImpl.Tpo -c
src/gnu/classpath/tools/gjdoc/DocImpl.java  -fPIC -o
src/gnu/classpath/tools/gjdoc/.libs/DocImpl.o
src/gnu/classpath/tools/gjdoc/DocImpl.java:220: error: Can't find constructor
`javax.swing.text.Segment([CII)' in type `javax.swing.text.Segment'.
            Segment segment = new Segment(text, startIndex, endIndex - startIndex);
                                  ^
src/gnu/classpath/tools/gjdoc/DocImpl.java:222: error: Can't find method
`setText(Ljavax/swing/text/Segment;)' in type `java.text.BreakIterator'.
            breakIterator.setText(segment);
                         ^
2 errors
make[2]: *** [src/gnu/classpath/tools/gjdoc/DocImpl.lo] Fehler 1
make[2]: *** Warte auf noch nicht beendete Prozesse...
Comment 16 Hanno Zysik (geki) 2005-07-27 11:18:52 UTC
corrected link, sorry.
http://geki.ath.cx/OOo/gjdoc-0.7.5.tar.bz2
Comment 17 Hanno Zysik (geki) 2005-07-29 18:15:35 UTC
I updated gjdoc and java-gcj-compat overlays. Both should merge now.

java-gcj-compat
http://geki.ath.cx/OOo/java-gcj-compat-4.0.1.tar.bz2
http://geki.ath.cx/OOo/java-gcj-compat-files

gjdoc
http://geki.ath.cx/OOo/gjdoc-0.7.5.tar.bz2

One issue remains. Having >1 gcc with gcj useflag merged. Then gcj links to
running gcc's version. This can cause strange errors. Especially gcj3 and gcj4
mixture.

As a workaround, I merged gcc3 without gcj useflag and gcc4 with gcj useflag.

Anyone up for a solution of that problem?
- is there a possibility to set an envvar for which gcj to use? like CC or JAVAC?
Comment 18 Hanno Zysik (geki) 2005-07-31 14:17:32 UTC
That issue is no issue. java-gcj-compat is a "Java SDK". If you want to use a
Java SDK you use java and javac which link to gij and gcj with java-gcj-compat.
gij and gcj links are only used if gcc is merged without gcj useflag. So no issue.

I added gij and gcj links because of OOo2. These should not be there.
Comment 19 Hanno Zysik (geki) 2005-09-10 19:56:22 UTC
I opened a thread on f.g.o.
http://forums.gentoo.org/viewtopic-p-2715924.html#2715924

Anyone interested in java-gcj-compat and/or GCJ as Java SDK replacement may have
a look there for latest information. At least a partly replacement because it is
just not.
Comment 20 Josh Nichols (RETIRED) gentoo-dev 2005-12-17 11:29:56 UTC
Lowering the priority a bit. Considering that the Java team is severly understaffed, and that gcj isn't a complete replacement for a JDK, it's not on the top of our list at the moment, and probably won't be for awhile.

That being said, it would be interesting to be able to build your system using just gcj.

Also, it is worth noting that one of our users is working on making a separate ebuild for gcj, so that would be useful once it is complete.
Comment 21 Hanno Zysik (geki) 2005-12-22 16:48:45 UTC
FYI, I got apache-ant 1.6.2 with gcj 4.1 merged. Some workarounds are needed to address this bug
http://gcc.gnu.org/ml/java/2005-12/msg00181.html

I think this is quite interesting since google and other addresses (i.e., fedora cvs) give no answers to this.

With this apache-ant version dev-java/bsf does not merge anymore because of some missing sun.tools... class. Good that I got a copy of bsf merged already.

Important packages that break with gcj:
dev-util/eclipse-sdk and dependencies (needs ant-{core,tasks}-1.6.5)
dev-java/jdbc-mysql (only gcj 4.1)
gcjwebplugin (unusable)
and others I do not know about...
Comment 22 Joël 2006-01-31 10:39:43 UTC
Hi,

I would like to make an ebuild for gcj-compiled Azureus, similar to what Anthony Green has just done for Red Hat.

I've already asked him a few questions, but I'd need more help.. I can't even build java-gcj-compat on gentoo (yet) !

Thanks in advance

Jo
Comment 23 Joël 2006-01-31 10:39:43 UTC
Hi,

I would like to make an ebuild for gcj-compiled Azureus, similar to what Anthony Green has just done for Red Hat.

I've already asked him a few questions, but I'd need more help.. I can't even build java-gcj-compat on gentoo (yet) !

Thanks in advance

Joël
Comment 24 Roc Vallès 2006-03-09 06:37:04 UTC
I'm really looking forward to finally being able to use gcj. It's a serious annoyance not to be able to set it as the system jdk.
Comment 25 Hanno Zysik (geki) 2006-04-20 10:00:16 UTC
Anyone interested in GCJ as Java SDK / RE may read this forums thread, please.
http://forums.gentoo.org/viewtopic-t-379693.html
Comment 26 Roc Vallès 2006-04-20 17:25:23 UTC
As I see in that forum thread, gcj does already build/run popular java software like azureus, and unlike other java implementations, it is free.

Is there a reason this isn't in java-config yet, other than no developer stepping up to merge it into portage?
Comment 27 Josh Nichols (RETIRED) gentoo-dev 2006-04-20 17:49:53 UTC
(In reply to comment #24)
> Is there a reason this isn't in java-config yet, other than no developer
> stepping up to merge it into portage?
> 

Certainly, there are several.

First is that the Java team is very understaffed, and is barely able to maintain our existing packages, let alone going into exciting new directions.

Second, our current resources are currently working fervously to move to a new system (read: new java-config and eclasses) that will let us unmask.

Thirdly, there are implementation details that need to be addressed. In particular, dev-java/gcj is now it's own package which builds all the gcc things it needs, then gcj itself. The toolchain team is extremely opposed to doing it this way at this time. The primary reason is that it isn't supported upstream to build this piece of gcc or that, but current developments are moving in this direction. So, instead, dev-java/gcj should make use of an existing gcc installed on the system that was built with USE=gcj.

Lastly, a developer would need to do the deed of adding it, and furthermore, be around to maintain it.
Comment 28 Stephan Sokolow 2006-05-17 00:15:00 UTC
There's also the problem that gnu-crypto and gnu-classpath-inetlib currently refuse to emerge with blackdown masked. I decided I cared more about the bragging rights (counting the number of non-libre packages on one hand) than a program or two that I never use anyway.
Comment 29 Hanno Zysik (geki) 2006-07-01 04:02:00 UTC
Resumee / Update:
Toolchain herd does not want a separate gcj package. I talked with Joshua Nichols about gcj-jdk. It could depend on USE="gcj" (optional USE="gtk", i.e., openoffice needs it) gcc package if some things are fixed:

- include patch for gcc PR13212 (http://gcc.gnu.org/PR13212)
- a sane way to link to libgcjawt.so and libgcj-VERSION.jar from system gcc set for gcj-jdk (lib/libjawt.so and lib/rt.jar)

I want to link gcj-jdk to the system gcc set instead of deep linking to a special gcc version.
One simple reason: mixing gcj versions from gcj-jdk / system gcc

See http://article.gmane.org/gmane.linux.gentoo.java/793
or http://forums.gentoo.org/viewtopic-p-3270147.html#3270147

Important gcj fixes and features are only on HEAD so this is for gcc-4.2.
Comment 30 Josh Nichols (RETIRED) gentoo-dev 2006-07-01 05:47:56 UTC
Adding toolchain for input.
Comment 31 Martin Schlemmer (RETIRED) gentoo-dev 2006-07-01 22:00:37 UTC
(In reply to comment #25)
> The toolchain team is extremely opposed to doing it this way at this time.
>
(In reply to comment #27)
> Resumee / Update:
> Toolchain herd does not want a separate gcj package.
>

I cannot really speak for all, and Mike may decide to slam this back in my face, but I cannot see why it could not be done.  The only issue will be that it should not conflict with any files from gcc (without gcj of course), and it might take a while, as like already mentioned you still have to build gcc to get gcj to build, and cannot use installed gcc.

To be honest, while I did gcc, gcj (and ada) was stuff I usually just checked if they build, and did not even install it my side when testing was done.  As I stated at the beginning of this bug, I was all for it, but due to my total lack of java knowledge, I sort of left it in the reporter's (or whoever wanted to take it) hands.  It will ease things our side, as it will then be under the care of the java herd.
Comment 32 SpanKY gentoo-dev 2006-07-01 23:54:57 UTC
it can be done, but so far we've been of the opinion that we're not about to go hacking apart the gcc build system

the idea was/is get upstream to make gcj an independent build and then we integrate that
Comment 33 Hanno Zysik (geki) 2006-07-02 03:28:19 UTC
(In reply to comment #30)
> it can be done, but so far we've been of the opinion that we're not about to go
> hacking apart the gcc build system

With the current gcj-jdk idea the gcc build system does not need to be touched.

> the idea was/is get upstream to make gcj an independent build and then we
> integrate that

What is the status?
Comment 34 Hanno Zysik (geki) 2006-07-11 15:37:16 UTC
Ok, may be I was a bit unclear before.

I did already some work on gcj integration into Gentoo. You may want to read this:
https://projects.gentooexperimental.org/expj/wiki/GCJ_as_a_JDK

Here are my ideas how to integrate gcj into Gentoo.

1. version
The overlay builds gcj as a separated package with a cloned toolchain.eclass (gcc-java.eclass). USE="gcj gtk" and 'is_gcj' code should be dropped from gcc package. Other than that there is nothing toolchain herd needs to do and maintain.

2. version
There is a gcc-java-2.eclass that inherits toolchain.eclass. To reduce code-doubling. Still, it builds a separate gcj package. It needs a one-liner fix to toolchain.eclass (commented in gcc-java-2.eclass). USE="gcj gtk" and 'is_gcj' code should be dropped from gcc package. Other than that nothing toolchain herd needs to do and maintain.

3. version
Create a gcj-jdk package that depends on USE="gcj" gcc package. With this way toolchain herd would need to tweak eselect compiler module to put (gc)jawt and libgcj-VERSION.jar (bootclasspath) to a unversion path. So that gcj-jdk is able to link to these and the runtime gcc/gcj version.

1. and 2. version do just fine.
3. version is quite easy to do if eselect compiler module is tweaked for the gcj-jdk requirements.

Is one of these ways ok for toolchain herd?

Why do I prefer the first two ways?
I just do not want to have gcc and gcj in sync. I want a "stable" gcc and a "newer" gcj version for latest fixes and enhancements.
Comment 35 Hanno Zysik (geki) 2006-07-21 06:52:15 UTC
Update of gcj-overlay.
- moved to "Version 2"
- found a way to unset toolchain's IUSE
- deleted gcc cruft from gcj package

One can use 'USE="gcj" gcc' the old way.
Or 'GCJ as a JDK / JRE' with dev-java/gcj-jdk.

Toolchain herd not needed for input anymore.
Though, Joshua Nichols wants their input.
Comment 36 Alon Bar-Lev (RETIRED) gentoo-dev 2008-01-02 19:30:27 UTC
It actually works!!!
I switch a more than a month ago, and I am happy not to have binaries on my system, apart from the blockers...
Please consider to support after gcc-4.3 be out.
Thanks!
Comment 37 Andrew John Hughes 2008-01-08 12:03:04 UTC
Can ~ppc64 be added to the gcj and gcj-jdk ebuilds please?
Also why does it depend on ecj 3.4 which hasn't yet been released?
Comment 38 Steven Newbury 2009-02-09 15:33:17 UTC
Created attachment 181443 [details]
Re-worked gcj-jdk ebuild

I've re-worked the gcj-jdk ebuild to support multiple gcj JDKs, each installed gcc (per SLOT) with USE=gcj can be selected and used from java-config as long as a correponding gcj-jdk is installed.  Also it now supports the gcjwebplugin as long as gcc is built with nsplugin and gtk USE flags.
Comment 39 Steven Newbury 2009-02-09 15:36:47 UTC
Created attachment 181445 [details]
Re-worked gcj-jdk ebuild (hopefully it uploads this time)
Comment 40 Steven Newbury 2009-02-09 15:39:20 UTC
Created attachment 181446 [details]
New gcj-jdk.env source file for re-worked ebuild
Comment 41 Steven Newbury 2009-02-09 15:40:38 UTC
Created attachment 181448 [details]
updated rebuild-classmap-db
Comment 42 Steven Newbury 2009-02-09 15:52:53 UTC
I just noticed the gcj-jdk in the java-gcj-overlay repo has been updated since the version I based off (including nsplugin support).  I'll merge the two and post a patch here if there is interest.

I am also maintaining a patch against the java-utils-2.eclass in the main portage tree implementing the features from the java-gcj-overlay version.  I'll resync and attach it here shortly.
Comment 43 Steven Newbury 2009-02-09 16:10:11 UTC
Created attachment 181454 [details, diff]
Patch against current java-utils-2.eclass

This patch against java-utils-2.eclass provides the functionality of the java-utils-2.class from the java-gcj-overlay, cleaned, re-synced and updated to work with gcc (/w USE=gcj) from the main portage tree.
Comment 44 Steven Newbury 2009-02-09 16:20:54 UTC
Having taken a closer look at the gcj-jdk ebuild currently in java-gcj-overlay, it's clearly older than the version I based off.  I'll leave it as is for now, unless anyone would care to comment..?
Comment 45 Steven Newbury 2009-02-09 17:40:29 UTC
Created attachment 181460 [details]
New gcj-jdk ebuild (Fixed multislot bug and cleaned up slightly)
Comment 46 Steven Newbury 2009-02-09 17:43:11 UTC
Created attachment 181462 [details]
gcj-jdk.env for new ebuild in previous attachment
Comment 47 Steven Newbury 2009-02-09 18:34:12 UTC
Just to be clear, in the attached ebuild, there is no need to have the compiler set the same version as the JDK.  As long as the relevant toolchain is installed with gcj support, this version of gcj-jdk will permit use of the gcj/gij JDK as "java" through java-config like any other JDK.  However, the default toolchain "gcj" will be used for compiling binaries, and running "gij" directly will execute the _toolchian_ version.  I personally feel this is the desirable behaviour.
Comment 48 Steven Newbury 2009-02-11 16:19:52 UTC
Since it's now possible to have multiple versions of gcj-jdk + gcc installed similtaneously there is extra scope to be hit by ABI incompatiblities from libgcj.  For example, compiled java from a gcc with a different libgcj ABI to the current gcj-jdk will result in failure.  As a partial solution, I have put some additional logic into java-utils-2.eclass to build with the gcj version that matches the current java JDK if that JDK is gcj-jdk.  Otherwise it uses gcj from the highest installed gcc version with gcj support.

I'll attach after further testing.
Comment 49 Steven Newbury 2009-02-11 16:21:32 UTC
Actually, it's a little smarter than I implied above since it compares the libgcj soversions to determine compatibility with the current gcj-jdk.
Comment 50 Steven Newbury 2009-02-12 02:11:03 UTC
I think I've now worked out all the bugs and issues as far as I can tell...
Comment 51 Steven Newbury 2009-02-12 02:30:23 UTC
Created attachment 181724 [details]
gcj-jdk environment source file
Comment 52 Steven Newbury 2009-02-12 03:40:45 UTC
Created attachment 181730 [details]
rebuild-classmap-db script ".in" source

Now that I have a separate classmap db for each ABI version, JAVA_PKG_CLASSMAP needs to point to the right place.
Comment 53 Steven Newbury 2009-02-12 03:58:44 UTC
Created attachment 181732 [details]
New gcj-jdk ebuild with lots of bugs fixed and made more consistent
Comment 54 Steven Newbury 2009-02-12 04:00:11 UTC
Created attachment 181733 [details]
java wrapper needs to point to correct classmap db
Comment 55 Steven Newbury 2009-02-12 04:05:21 UTC
Created attachment 181734 [details, diff]
Patch against portage java-utils-2.eclass to fully support gcj-jdk and native java packages
Comment 56 Steven Newbury 2009-02-12 04:06:29 UTC
Created attachment 181736 [details, diff]
java-pkg-2.eclass patch
Comment 57 Steven Newbury 2009-02-12 04:07:29 UTC
Created attachment 181737 [details, diff]
java-pkg-opt-2.eclass patch
Comment 58 Steven Newbury 2009-02-12 12:57:25 UTC
Created attachment 181770 [details, diff]
Patch against portage java-utils-2.eclass to fully support gcj-jdk and native java packages

Fixed rpath and added OPTIMIZE_CFLAGS for case when building native from java source.  Compiling a jar into a jar.so takes very large amounts of memory depending on the size of the jar, so it is necessary to minimize optimization, but when building from source this limitation does not exist, so honour the system CFLAGS.
Comment 59 Steven Newbury 2009-02-12 14:29:45 UTC
Created attachment 181782 [details]
Even better gcj-jdk ebuild

The ebuild now installs into ${PN}-${SLOT}-${libgcj_soversion} and links libgcj from the toolchain.  This allows the rpath for native binaries to keep working (ie finding the right libgcj) within a gcc SLOT as long as the ABI doesn't change.

The following java-utils-2.ebuild.patch obviously also needs applying to make this work.
Comment 60 Steven Newbury 2009-02-12 14:31:23 UTC
Created attachment 181783 [details]
java-utils-2.class patch with improved rpath handling
Comment 61 Steven Newbury 2009-02-12 14:39:57 UTC
Created attachment 181784 [details]
eclipse-ecj ebuild utilising the improved native machinery

The dev-java/eclipse-ecj ebuild currently in the tree doesn't work too well for me, and it gets even worse with the changes I've made in the bug.  I've changed the way it handles building the native binary to utilise the native infrastructure in java-utils-2.eclass.  This has had the added benefit of producing a *much* faster binary and lower memory requirements.  I've also removed the explicit support for compiling the jar with gcj, so it now always uses the system JDK (which may or may not be gcj-jdk).
Comment 62 Steven Newbury 2009-02-12 14:45:27 UTC
The java-utils-2.eclass patch could do with a little cleaning up.  Currently it puts all the new logic into java-pkg_native_init_, I really should break it out into some new functions, if for no other reason but to make it more readable.  I do believe I have found and fixed all the bugs and issues with utilising the gcj JDK and if others could test and/or review the work I've done here I would appreciate it.
Comment 63 Steven Newbury 2009-02-12 15:10:31 UTC
Created attachment 181786 [details]
gcj-jdk.env.in: fix JAVA_HOME bug

Oops
Comment 64 Steven Newbury 2009-02-12 15:13:19 UTC
Created attachment 181788 [details]
gcj-jdk ebuild: fix JAVA_HOME bug

Okay, it should be working now...  Anybody trying this, make sure you unmerge any old gcj-jdk versions.
Comment 65 Steven Newbury 2009-02-12 15:17:00 UTC
TODO?: Remove requirement to have separate gcj classmap DBs by always setting the rpath appropriately even when compiling jars.
Comment 66 Steven Newbury 2009-02-12 15:30:15 UTC
Close... next fix do it...
Comment 67 Steven Newbury 2009-02-12 15:46:27 UTC
Created attachment 181792 [details]
gcj-jdk ebuild: added symlinks for all libgcj* libs

It really does work now :)
Comment 68 Steven Newbury 2009-02-12 17:39:14 UTC
Created attachment 181801 [details, diff]
java-utils-2.eclass patch fix yet another bug
Comment 69 Steven Newbury 2009-02-12 17:53:13 UTC
Created attachment 181802 [details, diff]
java-pkg-2.eclass patch (previous version somehow lost a function)
Comment 70 Steven Newbury 2009-02-12 18:24:51 UTC
One current caveat: if a package, gjdoc for example supports gcj directly, and
gcc-config is set not set the same as java-config it is necessary to set
GCJ=gcj-<version> in the environment to point to the appropriate version.  I'll
look into it soon...
Comment 71 Steven Newbury 2009-02-13 01:40:24 UTC
Created attachment 181826 [details]
gcj-jdk ebuild

I attached the wrong version, I'm an idiot.
Comment 72 Alistair Bush (RETIRED) gentoo-dev 2009-02-13 07:37:55 UTC
Steven  while I appreciate all the work you are doing.  Could I suggest that we move this to somewhere that is easier to manage?

Maybe git for instance?  I could then manage a "central" repo if need be.

Otherwise maybe we could get you access to a java overlay.

Either come talk to me on #gentoo-java or email me at ali_bush at gentoo dot org.

if you are interested.
Comment 73 Steven Newbury 2009-02-13 09:13:57 UTC
(In reply to comment #72)
> Steven  while I appreciate all the work you are doing.  Could I suggest that we
> move this to somewhere that is easier to manage?
> 
> Maybe git for instance?  I could then manage a "central" repo if need be.
> 
> Otherwise maybe we could get you access to a java overlay.
> 
> Either come talk to me on #gentoo-java or email me at ali_bush at gentoo dot
> org.
> 
> if you are interested.
> 
Yes, thanks.  I'll get onto #gentoo-java later on today and discuss this with you.
Comment 74 Steven Newbury 2009-03-07 01:28:43 UTC
For anybody interested in this; there is a new overlay for gcj-jdk at http://github.com/alistair/new-gcj-overlay

I'd welcome any testers, I think it should be okay to use this bug for feedback?

The overlay contains much improved versions of the ebuilds included on this bug.
Comment 75 Mark Loeser (RETIRED) gentoo-dev 2009-07-04 00:12:20 UTC
Add toolchain back if you need us.
Comment 76 Miroslav Šulc gentoo-dev 2011-01-17 10:29:18 UTC
as far as i can see, gcj-jdk is now in tree, so closing this bug