/Erik
On 2014-06-03 16:52, Tim Bell wrote:
That's puzzling - how does rpm square with what ldd is reporting? Is glibc loaded dynamically, in which case my experiments are missing the point...hostname sc11137352 /opt/jprt/products/P1/jdk8-latest/jdk1.8.0/bin/java -version java version "1.8.0" Java(TM) SE Runtime Environment (build 1.8.0-b132) Java HotSpot(TM) Server VM (build 25.0-b70, mixed mode) ldd /opt/jprt/products/P1/jdk8-latest/jdk1.8.0/bin/java linux-gate.so.1 => (0x00110000) libpthread.so.0 => /lib/libpthread.so.0 (0x009aa000)libjli.so => /opt/jprt/products/P1/jdk8-latest/jdk1.8.0/bin/../lib/i386/jli/libjli.so (0x00111000)libdl.so.2 => /lib/libdl.so.2 (0x009a3000) libc.so.6 => /lib/libc.so.6 (0x0080d000) /lib/ld-linux.so.2 (0x007ed000) Tim On 06/03/14 08:14, Erik Joelsson wrote:And according to rpm, the version is: $ rpm -q glibc glibc-2.8-3.x86_64 /Erik On 2014-06-03 03:01, Tim Bell wrote:Hi - catching up on my email backlog:Not sure what glibc version that is, though.For Linux builds, others on build-dev@openjdk.java.net are more knowledgeable about glibc used in different JDK releases.Hmmm - these README-builds.html files do not mention a specific glibc version:http://hg.openjdk.java.net/jdk8u/jdk8u-dev/raw-file/tip/README-builds.htmlhttp://hg.openjdk.java.net/jdk7u/jdk7u-dev/raw-file/tip/README-builds.htmlI ran a little test on one of our Fedora 9 build/test systems: uname -aLinux sc11137352 2.6.25-14.fc9.i686 #1 SMP Thu May 1 06:28:41 EDT 2008 i686 i686 i386 GNU/Linuxgcc -v Using built-in specs. Target: i386-redhat-linuxConfigured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-cpu=generic --build=i386-redhat-linuxThread model: posix gcc version 4.3.0 20080428 (Red Hat 4.3.0-8) (GCC) cat -n hw.c 1 #include <stdio.h> 2 int main() { 3 printf("Hello world\n"); 4 } gcc -o hw hw.c ./hw Hello world ldd ./hw linux-gate.so.1 => (0x00110000) libc.so.6 => /lib/libc.so.6 (0x0080d000) /lib/ld-linux.so.2 (0x007ed000) Hope this helps- Tim On 05/23/14 00:13, Christian Thalinger wrote:On May 22, 2014, at 5:04 PM, Doug Simon <doug.si...@oracle.com <mailto:doug.si...@oracle.com>> wrote:On May 23, 2014, at 12:44 AM, Deneau, Tom <tom.den...@amd.com <mailto:tom.den...@amd.com>> wrote:Doug -- What glibc does Hotspot build against?I’m not sure - Christian may know (or know who knows).Looking at some wiki pages JDK 8 is building on: Fedora 9 / GCC 4.3Not sure what glibc version that is, though. Tim Bell is the right guy to ask.-Doug-----Original Message----- From: Doug Simon [mailto:doug.si...@oracle.com] Sent: Thursday, May 22, 2014 5:40 PM To: Caspole, Eric Cc: Deneau, Tom; Bernhard Urban Subject: Re: HSAIL unit tests fail when Okra library fails to loadOn May 22, 2014, at 11:19 PM, Eric Caspole <eric.casp...@amd.com <mailto:eric.casp...@amd.com>> wrote:an older glibc to help avoid this problem? What is the oldest distro youHi Doug,Do you think it is worth it to build the built in Okra simulator withintend to support with Graal?In theory we should support whatever HotSpot does although in practicewe only need it to work on OSes for which we build distributions. However, I think it's fine (for now at least) if we just cleanlyignore/short-circuit the HSAIL unit tests in question on platforms withan older glibc. -DougOracle Linux 6.5 which has an old version of glibc (GLIBC 2.12). WhileOn 05/22/2014 07:33 AM, Doug Simon wrote:Hi Tom, Eric, We're in the process of making GraalVM binary builds that work ontesting this build, the HSAIL tests that use the Okra library failbecause libokra_x86_64.so is built against a version of GLIBC later than2.12. However, the failure message is very confusing. For example:test(com.oracle.graal.compiler.hsail.test.Vec3ObjStreamClassCastTest)$ mx --vm server unittest Vec3ObjStreamClassCastTest GraalJUnitCore JUnit version 4.11 .E Time: 0.77 There was 1 failure: 1)java.lang.NoClassDefFoundError: Could not initialize classcom.amd.okra.OkraContextcom.oracle.graal.compiler.hsail.test.infra.KernelTester.<init>(KernelTesatter.java:129)com.oracle.graal.compiler.hsail.test.infra.GraalKernelTester.<init>(GraaatlKernelTester.java:63)com.oracle.graal.compiler.hsail.test.SingleExceptionTestBase.<init>(SingatleExceptionTestBase.java:32)com.oracle.graal.compiler.hsail.test.Vec3ObjStreamClassCastTest.<init>(Vatec3ObjStreamClassCastTest.java:31)at sun.reflect.NativeConstructorAccessorImpl.newInstance0(NativeMethod)sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAatccessorImpl.java:62)sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConsattructorAccessorImpl.java:45)atjava.lang.reflect.Constructor.newInstance(Constructor.java:408)org.junit.runners.BlockJUnit4ClassRunner.createTest(BlockJUnit4ClassRunnater.java:195)org.junit.runners.BlockJUnit4ClassRunner$1.runReflectiveCall(BlockJUnit4atClassRunner.java:244)to load the Okra library (preferably issuing a message if it's for any other reason than the library not being available). One way to triggerCan you please make sure the HSAIL test harness recognizes a failurethis is to fake a bad library:$ mkdir -p resources/okra/Linux $ echo "bad" >resources/okra/Linux/libokra_x86_64.so $ jar uvf lib/okra-1.9-with-sim.jarresources/okra/Linux/libokra_x86_64.so$ mx --vm server unittest Vec3ObjStreamClassCastTest -Doug