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
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.
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 ?
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) ?
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.
http://freshmeat.net/projects/jdkgcj/ Have a look at this..
Any news about this "bug"?
Most distros seem to use http://sourceware.mirrors.tds.net/pub/sourceware.org/rhug/java-gcj-compat/
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.
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
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?
javadoc is necessary. I was too optimistic. Well, I did not get the binary
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?
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 :-)
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.
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...
corrected link, sorry. http://geki.ath.cx/OOo/gjdoc-0.7.5.tar.bz2
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?
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.
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.
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.
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...
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
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
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.
Anyone interested in GCJ as Java SDK / RE may read this forums thread, please. http://forums.gentoo.org/viewtopic-t-379693.html
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?
(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.
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.
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.
Adding toolchain for input.
(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.
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
(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?
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.
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.
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!
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?
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.
Created attachment 181445 [details] Re-worked gcj-jdk ebuild (hopefully it uploads this time)
Created attachment 181446 [details] New gcj-jdk.env source file for re-worked ebuild
Created attachment 181448 [details] updated rebuild-classmap-db
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.
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.
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..?
Created attachment 181460 [details] New gcj-jdk ebuild (Fixed multislot bug and cleaned up slightly)
Created attachment 181462 [details] gcj-jdk.env for new ebuild in previous attachment
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.
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.
Actually, it's a little smarter than I implied above since it compares the libgcj soversions to determine compatibility with the current gcj-jdk.
I think I've now worked out all the bugs and issues as far as I can tell...
Created attachment 181724 [details] gcj-jdk environment source file
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.
Created attachment 181732 [details] New gcj-jdk ebuild with lots of bugs fixed and made more consistent
Created attachment 181733 [details] java wrapper needs to point to correct classmap db
Created attachment 181734 [details, diff] Patch against portage java-utils-2.eclass to fully support gcj-jdk and native java packages
Created attachment 181736 [details, diff] java-pkg-2.eclass patch
Created attachment 181737 [details, diff] java-pkg-opt-2.eclass patch
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.
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.
Created attachment 181783 [details] java-utils-2.class patch with improved rpath handling
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).
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.
Created attachment 181786 [details] gcj-jdk.env.in: fix JAVA_HOME bug Oops
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.
TODO?: Remove requirement to have separate gcj classmap DBs by always setting the rpath appropriately even when compiling jars.
Close... next fix do it...
Created attachment 181792 [details] gcj-jdk ebuild: added symlinks for all libgcj* libs It really does work now :)
Created attachment 181801 [details, diff] java-utils-2.eclass patch fix yet another bug
Created attachment 181802 [details, diff] java-pkg-2.eclass patch (previous version somehow lost a function)
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...
Created attachment 181826 [details] gcj-jdk ebuild I attached the wrong version, I'm an idiot.
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.
(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.
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.
Add toolchain back if you need us.
as far as i can see, gcj-jdk is now in tree, so closing this bug
