I don't think they are conflicting. /lib/libc.so.6 is part of the package glibc-2.8-3.

/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.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








Reply via email to