GNU Classpath 0.16 was released some days ago. Reproducible: Always Steps to Reproduce:
Created attachment 63379 [details] Updated ebuild I fixed the dependencies for Classpath: - libart_lgpl is out - gtk+ is now >=2.4 (was >=2) - cairo-0.5 (!) The cairo lib is only needed if the corresponding flag is set. I already applied the wish mentioned in bug #93552 to move cairo to media-libs (instead of x11-libs). Using the ebuild from bug #93552 with this one works without problems here (x86).
0.17 out now. Seems like mostly bug fixes to 0.16.
I'm not sure if the dependency on gdk-pixbuf is necessary. I think GNU Classpath can use version 2 of the gdkpixbuf library, which comes with gtk 2.4+. Classpath seemed to build ok with gtk's version of gdk-pixbuf anyway. I haven't done much testing with the classpath I merged, however. A SPEC file (http://lists.gnu.org/archive/html/classpath/2005-03/msg00159.html) sent to the classpath ml listed gdk-pixbuf 2.0 as a dep. That doesn't necessarily mean the SPEC file was correct, of course. I thought I'd post this comment to see if anyone with more knowledge could shed some light. Meanwhile, I'll test my classpath ebuild some more. P.S. I changed the subject to reflect that 0.17 is out. I hope no one minds.
Created attachment 68395 [details] ebuild for classpath 0.18 Since cairo is still in x11-libs I changed this again in this ebuild. Btw: Although Classpath was only updated specifically to the API changes of cairo 0.5.0 it still compiles and works with 1.0.0 Btw2: This ebuild does not support the new Qt4 peers. Lets look how much integration of Qt4 in Gentoo and Classpath has happened in two months and I'll fix that with CP's next release.
renamed.
Created attachment 68400 [details, diff] patch for ebuild in short. rev1.4 to rev1.5 change plus my changes. Header cleanup gtk -> gtk2 useflag gcj useflag gdk-pixbuf dep not needed -> pulls gtk1. no go.
Hi some remarks: gcj useflag You need at least GCJ3.4 or the build will break. I thought it would add unnecessary overhead to the ebuild (detecting right gcj3.4, fallback to jikes on x86 currently) and left it out. For the future Classpath (>0.18) one even needs GCJ4.0. Given that GCJ is not the best, not the fastest compiler and Gentoo is *not* exploiting its native compilation feature (hint. hint.) I propose to use jikes (and ecj) in all places. gdk-pixbuf dep not needed I'll ask the classpath team about this.
gcj useflag: i added sys-devel/gcc-4.0.1 depend for gcj. ~x86 runs that compiler. sys-devel/gcc got gcj useflag. so why not using?! senseless to me. but gentoo devs sure know better. does not matter if it is the best or fastest. it is an alternative to sun-jdk/blackdown-jdk which some people dislike. gdk-pixbuf depend: drop it because it is _gtk+-1_. pulls gtk1 stuff which is just not needed! gnu-classpath configure checks for gdk-pixbuf-2.0 pkg-config file. no idea what package ships gdk-pixbuf-2.0. may be gtk+-2? however, i got it without gdk-pixbuf package.
Yep gdk-pixbuf-2.0 comes with gtk+2. So it is not needed as a dependency you said (next classpath release will reflect this change in its README/INSTALL file). Your GCJ addition looks good. GCJ4.0.1 is a good choice (especially for the future). Then there is only one thing: + gtk2? ( >=x11-libs/gtk+-2.4 >=media-libs/libart_lgpl-2.1 ) libart_lgpl is not needed any more.
I did not touch that part (libart_lgpl). It is from rev1.5. You may just drop it so.
Created attachment 68459 [details] package.env for java-config classpath foer this purpose: $ java-config -l ... [classpath] Free core class libraries for use with virtual machines and compilers for the Java programming language (/usr/share/classpath/package.env) ... $ java-config --classpath=classpath /usr/share/classpath/glibj.zip At least OOo2 GCJ build needs that for canvas/source/java part.
Created attachment 68466 [details, diff] ebuild patch with discussed changes and package.env generation No idea if 'files="${files%:}"' or 'files="${files%%:}"' is correct. Both gave same results on tests.
gnu-classpath-0.18 was just added to the tree. I had to drop the cairo use flag because the required cairo version is still package.masked and I can't add the gcj use flag because of the same reason. I also feel the it is the task of the vm/runtime environment to now where the core library is located so I did not put the package.env installation. Choosing the compiler is something that we are looking in the future and ecj will probably be our compiler of choice. You can reopen this bug or make a new one for the package.env file if you really want it to be added. But thanks for the work you all. You can find the gcj use flag in the experimental tree but I haven't tested it.
