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.html
http://hg.openjdk.java.net/jdk7u/jdk7u-dev/raw-file/tip/README-builds.html
I ran a little test on one of our Fedora 9 build/test systems:
uname -a
Linux sc11137352 2.6.25-14.fc9.i686 #1 SMP Thu May 1 06:28:41 EDT
2008 i686 i686 i386 GNU/Linux
gcc -v
Using built-in specs.
Target: i386-redhat-linux
Configured 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-linux
Thread 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.3
Not 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 load
On May 22, 2014, at 11:19 PM, Eric Caspole <eric.casp...@amd.com
<mailto:eric.casp...@amd.com>> wrote:
Hi Doug,
Do you think it is worth it to build the built in Okra simulator
with
an older glibc to help avoid this problem? What is the oldest
distro you
intend to support with Graal?
In theory we should support whatever HotSpot does although in
practice
we 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 cleanly
ignore/short-circuit the HSAIL unit tests in question on
platforms with
an older glibc.
-Doug
On 05/22/2014 07:33 AM, Doug Simon wrote:
Hi Tom, Eric,
We're in the process of making GraalVM binary builds that work on
Oracle Linux 6.5 which has an old version of glibc (GLIBC 2.12).
While
testing this build, the HSAIL tests that use the Okra library fail
because libokra_x86_64.so is built against a version of GLIBC
later than
2.12. However, the failure message is very confusing. For example:
$ mx --vm server unittest Vec3ObjStreamClassCastTest
GraalJUnitCore
JUnit version 4.11
.E
Time: 0.77
There was 1 failure:
1)
test(com.oracle.graal.compiler.hsail.test.Vec3ObjStreamClassCastTest)
java.lang.NoClassDefFoundError: Could not initialize class
com.amd.okra.OkraContext
at
com.oracle.graal.compiler.hsail.test.infra.KernelTester.<init>(KernelTes
ter.java:129)
at
com.oracle.graal.compiler.hsail.test.infra.GraalKernelTester.<init>(Graa
lKernelTester.java:63)
at
com.oracle.graal.compiler.hsail.test.SingleExceptionTestBase.<init>(Sing
leExceptionTestBase.java:32)
at
com.oracle.graal.compiler.hsail.test.Vec3ObjStreamClassCastTest.<init>(V
ec3ObjStreamClassCastTest.java:31)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorA
ccessorImpl.java:62)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingCons
tructorAccessorImpl.java:45)
at
java.lang.reflect.Constructor.newInstance(Constructor.java:408)
at
org.junit.runners.BlockJUnit4ClassRunner.createTest(BlockJUnit4ClassRunn
er.java:195)
at
org.junit.runners.BlockJUnit4ClassRunner$1.runReflectiveCall(BlockJUnit4
ClassRunner.java:244)
Can you please make sure the HSAIL test harness recognizes a
failure
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
trigger
this 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.jar
resources/okra/Linux/libokra_x86_64.so
$ mx --vm server unittest Vec3ObjStreamClassCastTest
-Doug
