Trolltech's newly released Qt Jambi is a Java library that integrates Qt and Java enabling developers to write Qt applications in Java. Qt Jambi is dual-licensed under the GPL and Trolltech's proprietary license. The GPL licensed source tarball can be found at http://www.trolltech.com/download?target=ftp://ftp.trolltech.com/qtjambi/source/qtjambi-gpl-src-4.3.0_01.tar.gz. Reproducible: Always Steps to Reproduce:
*** Bug 181141 has been marked as a duplicate of this bug. ***
Just wanted to add some notes on my experience with using both the binary build and compiling from source: With the binary build for 64bit, the bundled designer software still looks for a 32bit jvm to run. I had to symbolically link the amd64 folder in /opt/sun-jdk-1.6.0.01 to i386 and within that I also had to symbolically link server to client so that libjvm.so could be found. They're also using JAVADIR to find the jvm and JAVADIR must be such that $JAVADIR/jre/lib/i386/client/libjvm.so can be found. I'm looking in the code to change this and when I do I'll upload the patch for amd64. This shouldn't be a problem on 32bit systems, although please correct me if I'm wrong. Also, to get the c++ libraries to build I had to compile and install my own version of Qt4 in my home folder such that the source and build were installed in the same place. This means we'll need to unpack qt4.3.0 source somewhere in the ebuild to make it accessible and possibly modify the pro files to fit gentoo's build of qt4. (I'm sure this is possible with some eclass that I haven't had to touch yet for qt). Also, the eclipse plugin works great for 32bit eclipse but there is still no version for 64bit. Since the eclipse plugin builds for gentoo are in the air for now, this may be better to just let the user manage in the same fashion. Be aware that the eclipse plugin is for 32bit only as of right now and also depends on the CDT plugin (for C++). (I installed my own eclipse32 folder in /opt just for the plugin and use eselect java-vm to get to a 32 bit jvm...sucks but it works) Anyhow, I'm interested in making an ebuild and curious who else would like to help. Thanks
I've been working on this all day. Will advise soon.
Okay, I've committed my ebuild as dev-java/qtjambi. I've been toying with it quite a bit, but it probably is far from perfect. Please try it out and advise.
Wow, that was amazingly quick. You must be interested in using qtjambi as well ;) Anyhow, great job on the ebuild, mostly works on my amd64 system. The only problem I encountered was one warned about in the build instructions of the qtjambi source. (I've attached the output of the error below) Basically, javac runs out of memory during the compile process (javac @java_files). To fix this you must pass the -J-Xmx1024 (note the capital X missing from QtJambi's build instructions) flag to javac to allow it to use 1gb of memory. I'm not sure if this happening because java_files references 631 files (ie 631 command line arguments) or if it's actually in the code it's compiling. My guess is that splitting this java_files in two (or three...) and specifying a couple more runs of javac might fix this issue but I'll just have to play around and see. In any event the ebuild finishes successfully despite the failing of javac (out of memory) and everything installs just fine. The jar, of course, is incomplete for me because of the above. I'm going to edit the ebuild and add the flag to javac just to see it all work out, in which case you can add the ~amd64 flag as well. Also, just out of curiousity did you get this out of memory error on x86? If not then we might we might want to look into putting a check for amd64 and warning about the memory usage and also provide a bin build as well for those that might not have enough memory. Anyhow, thanks and godbless Gentoo. PORTION OF THE BUILD THAT FAILS FOR OUT OF MEMORY ISSUES: * Running juic updated: com.trolltech.demos.imageviewer.Ui_AboutImageViewer updated: com.trolltech.demos.imageviewer.Ui_MainWindow updated: com.trolltech.examples.Ui_CalculatorDockable updated: com.trolltech.examples.Ui_CalculatorNormal updated: com.trolltech.examples.Ui_CalculatorSimple updated: com.trolltech.examples.Ui_ChatDialog updated: com.trolltech.examples.Ui_SimpleUIExample updated: com.trolltech.examples.Ui_SimpleUIExampleMainWindow updated: com.trolltech.examples.stylesheet.Ui_MainWindow updated: com.trolltech.examples.stylesheet.Ui_StyleSheetEditor updated: com.trolltech.launcher.Ui_Launcher juic: updated 11 files * Compiling java files The system is out of resources. Consult the following stack trace for details. java.lang.OutOfMemoryError: Java heap space at com.sun.tools.javac.util.List.of(List.java:74) at com.sun.tools.javac.comp.MemberEnter.addEnumMembers(MemberEnter.java: 432) at com.sun.tools.javac.comp.MemberEnter.finishClass(MemberEnter.java:407 ) at com.sun.tools.javac.comp.MemberEnter.finish(MemberEnter.java:1000) at com.sun.tools.javac.comp.MemberEnter.complete(MemberEnter.java:967) at com.sun.tools.javac.code.Symbol.complete(Symbol.java:386) at com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:758) at com.sun.tools.javac.code.Symbol$ClassSymbol.flags(Symbol.java:690) at com.sun.tools.javac.comp.Resolve.isAccessible(Resolve.java:124) at com.sun.tools.javac.comp.Resolve.loadClass(Resolve.java:843) at com.sun.tools.javac.comp.Resolve.findIdentInPackage(Resolve.java:1011 ) at com.sun.tools.javac.comp.Attr.selectSym(Attr.java:1918) at com.sun.tools.javac.comp.Attr.visitSelect(Attr.java:1832) at com.sun.tools.javac.tree.JCTree$JCFieldAccess.accept(JCTree.java:1522 ) at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:360) at com.sun.tools.javac.comp.Attr.attribType(Attr.java:390) at com.sun.tools.javac.comp.Annotate.enterAnnotation(Annotate.java:126) at com.sun.tools.javac.comp.MemberEnter.enterAnnotations(MemberEnter.jav a:743) at com.sun.tools.javac.comp.MemberEnter.access$300(MemberEnter.java:42) at com.sun.tools.javac.comp.MemberEnter$5.enterAnnotation(MemberEnter.ja va:711) at com.sun.tools.javac.comp.Annotate.flush(Annotate.java:95) at com.sun.tools.javac.comp.Annotate.enterDone(Annotate.java:87) at com.sun.tools.javac.comp.Enter.complete(Enter.java:472) at com.sun.tools.javac.comp.Enter.main(Enter.java:429) at com.sun.tools.javac.main.JavaCompiler.enterTrees(JavaCompiler.java:81 9) at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:727) at com.sun.tools.javac.main.Main.compile(Main.java:353) at com.sun.tools.javac.main.Main.compile(Main.java:279) at com.sun.tools.javac.main.Main.compile(Main.java:270) at com.sun.tools.javac.Main.compile(Main.java:69) at com.sun.tools.javac.Main.main(Main.java:54) >>> Source compiled. (installs fine) In reply to comment #4) > Okay, I've committed my ebuild as dev-java/qtjambi. I've been toying with it > quite a bit, but it probably is far from perfect. Please try it out and > advise. >
Well, adding the flag to javac in the ebuild as mentioned above fixes my issue for ~amd64. So, I'd say we're good to go on the amd64 keyword. I'm going to experiment with dividing the java_files up into smaller files to see if we can get around the javac out of memory problem. Another thing, now that I look at it, looks as though designer isn't being built from src and only comes from the binary build. I've tried to get this to work with the designer provided by gentoo's qt4 package but I can't seem to get it to load. In doing this I've been hacking the designer.sh wrapper that comes with the binary builds to point to /usr/bin/designer as well as modifying the env variables contained in the script. Have you been able to get this to work? If not, we definitely need a binary ebuild in the mean time because juic won't work without the jambi-enabled designer package to output *.juic files. Hmmm... I'm also going to put in a request upstream with the guys at trolltech for a 64bit version of the eclipse integration package. For now, this and the stand-alone designer issue are the only reason for having a 32bit version of qtjambi on my system.
Everything is still really experimental now :) I'm thinking about moving the .so files that are built into /usr/lib/qt4 instead of /usr/lib. I wasn't able to get qtjambi.jar to utilize those libaries until I set LD_LIBRARY_PATH. I'm hoping this fixes that. I'll look in putting the javac flag in tomorrow. I haven't played at all with the designer stuff yet. Will check it out.
reassigning
Committed -r1 of the ebuild. This should put designer stuff in the right location now, and it uses ejavac. Still haven't put in the -X flag to the compiler yet. Going to wait until this syncs with the mirrors so I can try it out on one of my other machines, then see how that goes.
(In reply to comment #5) > > Basically, javac runs out of memory during the compile process (javac > @java_files). To fix this you must pass the -J-Xmx1024 (note the capital X > missing from QtJambi's build instructions) flag to javac to allow it to use 1gb > of memory. > This is a general issue with amd64. amd64 uses more memory because of the double pointer size / server vm / etc. Using -Xmx1024 is a bit problematic because I think it might not work on machines with less much less memory than 1GB so the preferred solution is to do this stuff in the eclass via detection of available memory.
(In reply to comment #10) > > This is a general issue with amd64. amd64 uses more memory because of the > double pointer size / server vm / etc. Using -Xmx1024 is a bit problematic > because I think it might not work on machines with less much less memory than > 1GB so the preferred solution is to do this stuff in the eclass via detection > of available memory. > In the mean time java-pkg_force-compiler ecj-3.2 and depending on =dev-java/eclipse-ecj-3.2* should work around this issue. As for the native libs you should be registering them using java-pkg_regso and then you should be able to do java -Djava.library.path="$(java-config -di qtjambi)"
> As for the native libs you should be registering them using > java-pkg_regso and then you should be able to do " > java -Djava.library.path="$(java-config -di qtjambi)" I'm pretty sure that when the qtjambi loads, it has it's own internal routine for trying to find these particular libraries, and doesn't look at java related paths. So I think sticking them in with the other Qt stuff is probably going to work better. I'm not sure what _regso does; if it's important or not? I just started playing with using _doso for the installation.
hmm, not sure how I got cc'd
(In reply to comment #12) > > I'm not sure what _regso does; if it's important or not? I just started > playing with using _doso for the installation. > java-pkg_regso is used if it's for example installed using make install. It doesn't need to be used if you install it using java-pkg_doso (which is just install + regso).
Without calling regso or doso java-config is not aware of the sharied libraries and java-config -i doesn't work properly. All the JNI Java code I have seen so far has relied on the Java platform to locate the shared libraries.
I added doso for the -r1 ebuild. I'll experiment though. I might be nicer to tuck these shared libraries into the /usr/share/qtjambi-4/ structure as long as the java library can find them happily when it starts up.
no more comments assumes this is working okay for everyone. closing.
