Acording to http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=201 Shark should run and compile on amd64, but for Gentoo it does not, due to a relocation/PIC issue with sys-devel/llvm: Linking vm... /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/LLVMX86AsmPrinter.o: relocation R_X86_64_32 against `llvm::MachineModuleInfo::ID' can not be used when making a shared object; recompile with -fPIC /usr/lib/LLVMX86AsmPrinter.o: could not read symbols: Bad value collect2: ld returned 1 exit status { \ echo Linking launcher...; \ \ gcc -m64 -Xlinker -O1 -m64 -export-dynamic -L `pwd` -o gamma launcher.o -ljvm -lm -ldl -lpthread; \ \ } Linking launcher... /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -ljvm collect2: ld returned 1 exit status make[6]: *** [gamma] Error 1 make[6]: Leaving directory `/var/tmp/portage/dev-java/icedtea6-1.4/work/icedtea6-1.4/openjdk/control/build/linux-amd64/hotspot/outputdir/linux_zero_shark/product' dev-java/icedtea6 + shark should probably depend on "amd64? ( sys-devel/llvm[pic] )". Reproducible: Always
PS: I just realised the ebuild does not at all depend on sys-devel/llvm, so apparently it selects the wrong one when llvm is also installed on the system.
Ok, figured it out. USE=shark *does* depend on llvm being installed, it is just forgotten in DEPEND... So my originaly proposed fix applies.
Created attachment 180892 [details, diff] ebuild-patch so far Attached my patch to the ebuild, not finished/tested, since bug #257568 prevents building a compatible llvm.
After fixing the llvm build as described in bug #257568, icedtea6 builds and runs fine with shark on amd64. (Short test using an own small scale project.) The attached patch was sufficient.
Created attachment 210944 [details, diff] shark patch for icedtea6-1.6.2.ebuild Compiles and runs without problems on x86_64 (I used llvm-2.6 from main tree).
Since this is the main bug about Shark I add my info about PPC here: dev-java/icedtea-6.1.10.3 with USE="zero shark" and this patch WORK fine on PPC, a lot faster than zero only. I'd like to suggest to make icedtea a replacement for the annoying manual-binary-fetched IBM JDK on ppc soon, at least for ~ppc. Applications such as Hibiscus don't even work with IBM because of SUN classes, but work well with icedtea. Before Shark, zero-only was just too slow, but Zero/Shark is a realistic alternative now. Please mention in the PPC-FAQ and put some keywords to make it more simple to emerge. The only way as of today: # tail -n 4 /etc/portage/package.keywords dev-java/gcj-jdk ~ppc dev-java/icedtea ~ppc dev-java/ecj-gcj ~ppc sys-apps/lsb-release ~ppc sys-devel/gcc ~ppc # emerge -1 dev-java/gcj-jdk =virtual/jdk-1.5.0 # emerge --onlydeps -at icedtea # USE="zero shark" emerge icedtea As for the latest icedtea-6.1.10.4 build process still fails with USE="shark": Using java runtime at: /var/tmp/portage/dev-java/icedtea-6.1.10.4/work/icedtea6-1.10.4/bootstrap/jdk1.6.0/jre java version "1.6.0_22" OpenJDK Runtime Environment (IcedTea6 1.10.3) (Gentoo build 1.6.0_22-b22) OpenJDK Shark VM (build 20.0-b11, mixed mode) Stack dump: 0. Running pass 'Loop Pass Manager' on function '@"java.lang.String::indexOf"' 1. Running pass 'Loop Strength Reduction' on basic block '%bci_55' # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (os_linux_zero.cpp:270), pid=32006, tid=1873278080 # fatal error: caught unhandled signal 11 # # JRE version: 6.0_22-b22 # Java VM: OpenJDK Shark VM (20.0-b11 mixed mode linux-ppc ) # Derivative: IcedTea6 1.10.4 # Distribution: Built on Gentoo Base System release 2.0.3 (Sat Oct 22 10:37:33 CEST 2011)
Add: As mentioned in bug 388325 llvm needs a linking work-around to be able to emerge icedtea with shark: ln -s /usr/lib/llvm/libLLVM-2.8.so /usr/lib/
Currently there is no Shark and in the foreseeable future no more than one JVM per architecture will be officially supported. Only the one known to work best. An I_KNOW_WHAT_I_DO style var or similar to allow easier testing of alternative JVMs I can imagine though. About the other bug in this bug, ppc/ppc64 is supported through CACAO in icedtea:6 and JamVM in icedtea:7 should be well usable. From my experience CACAO was the better choice even when Shark was available. If Shark comes back depends on upstream.