The PGI compilers were installed in a dual Opteron system with two nodes running Rocks Cluster 3.3.0. I got the following errors when invoking the pgdbg:
PGDBG 6.0-4 x86-64 (Workstation, 4 CPU)
Copyright 1989-2000, The Portland Group, Inc. All Rights Reserved.
Copyright 2000-2005, STMicroelectronics, Inc. All Rights Reserved.
Exception in thread “main” java.lang.UnsatisfiedLinkError: /usr/pgi/linux86-64/6.0/jre/lib/i386/libawt.so: libXp.so.6: cannot open shared object file: No such file or directory
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503)
at java.lang.Runtime.loadLibrary0(Runtime.java:788)
at java.lang.System.loadLibrary(System.java:834)
at sun.security.action.LoadLibraryAction.run(LoadLibraryAction.java:50)
at java.security.AccessController.doPrivileged(Native Method)
at java.awt.Toolkit.loadLibraries(Toolkit.java:1437)
at java.awt.Toolkit.(Toolkit.java:1458)
at splashLoader.main(Unknown Source)
The library libXp.so.6 is located in /usr/X11R6/lib64/ on our system, and the file /etc/ld.so.conf contains the entry of /usr/X11R6/lib64.
Hi,
To work around this problem, you should install version 1.5 of the java JRE on the system that is running PGDBG. It is available for download from www.java.com (click on the “Download Now” button). After installing it, set your PGI_JAVA system environment variable to the absolute path of the java executable in this new installation. For example, let’s say you installed the JRE in /opt/java, then you
will set the PGI_JAVA environment variable the following way:
(csh/tcsh)
setenv PGI_JAVA /opt/java/jre/bin/java
(sh/bash)
export PGI_JAVA=/opt/java/jre/bin/java
You’ll need to set this variable prior to running the PGDBG GUI or PGPROF. For our next major release we will bundle the 1.5 java jre.
I’ve got a similar issue. I’ve set PGI_JAVA to /usr/java/jre1.5.0_04/bin/java before compiling with the -pg option. The machine in question is a quad opteron running Centos 4.1. The message I get is
pgprof -exe oceanS gmon.out
[jevans@evans-temp srcS-pgi]$ pgprof -exe oceanS gmon.out
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at splashLoader$1.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.UnsatisfiedLinkError: /opt/pgi/linux86-64/6.0/lib/libjpgprof.so: /opt/pgi/linux86-64/6.0/lib/libjpgprof.so: cannot open shared object file: No such file or directory
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(Unknown Source)
at java.lang.ClassLoader.loadLibrary(Unknown Source)
at java.lang.Runtime.load0(Unknown Source)
at java.lang.System.load(Unknown Source)
at jpgprof.main(Unknown Source)
… 6 more
I can’t even get text mode to work, using the -text option gives basically the same message. The shared object file clearly exists…
Are you positive that /opt/pgi/linux86-64/6.0/lib/libjpgprof.so exists on the node that you are launching PGPROF on? It is a dynamic library, which means it does not get loaded until after you launch PGPROF. I suppose you could also try setting the path to libpgprof.so in your LD_LIBRARY_PATH (although this should not be needed). For example:
Just a follow-up to my previous message…you said that libjpgprof.so does exist. What directory does it exist in? /opt/pgi/linux86-64/6.0/lib ?
The libjpgprof.so (for PGPROF 6.0) and libjpgdbg.so (for PGDBG 6.0) should live in $PGI/{linux86 | linux86-64}/6.0/lib (or in your case /opt/pgi/linux86-64/6.0/lib).
This particular case is an application running in serial mode, so it’s definitely not a case of a node not having access to the filesystem on which the shared libraries reside. Nonetheless, things weren’t quite as I thought. I was trying to solve the gui problem at the same time as trying to solve the text mode problem, and one was getting in the way of the other. Text mode seems to work without any special settings at all. But setting PGI_JAVA seems to prevent text mode from working (hope the output below isn’t too muddled).
Exception in thread “main” java.lang.UnsatisfiedLinkError: /opt/pgi/linux86-64/6.0/lib/libjpgprof.so: /opt/pgi/linux86-64/6.0/lib/libjpgprof.so: cannot open shared object file: No such file or directory
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(Unknown Source)
at java.lang.ClassLoader.loadLibrary(Unknown Source)
at java.lang.Runtime.load0(Unknown Source)
at java.lang.System.load(Unknown Source)
at jpgprof.main(Unknown Source)
And setting LD_LIBRARY_PATH in conjunction with PGI_JAVA yields
/usr/java/jre1.5.0_04/bin/java: relocation error: /opt/pgi/linux86-64/6.0/lib/libpthread.so.0: symbol _h_errno, version GLIBC_2.2.5 not defined in file libc.so.6 with link time reference
In trying to get gui mode working, various attempts yield
[jevans@evans-temp srcS]$ pgprof -exe oceanS gmon.out
Exception in thread “main” java.lang.UnsatisfiedLinkError: /opt/pgi/linux86-64/6.0/jre/lib/i386/libawt.so: libXp.so.6: cannot open shared object file: No such file or directory
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586)
blah blah blah
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
blah blah blah
Caused by: java.lang.UnsatisfiedLinkError: /opt/pgi/linux86-64/6.0/lib/libjpgprof.so: /opt/pgi/linux86-64/6.0/lib/libjpgprof.so: cannot open sharedobject file: No such file or directory
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
blah blah blah
/usr/java/jre1.5.0_04/bin/java: relocation error: /opt/pgi/linux86-64/6.0/lib/libpthread.so.0: symbol _h_errno, version GLIBC_2.2.5 not defined in file libc.so.6 with link time reference
I can say that the relocation errors that you are getting when you set LD_LIBRARY_PATH is probably due the lack of “:$LD_LIBRARY_PATH” at the end of “LD_LIBRARY_PATH=”. There’s probably other things in your LD_LIBRARY_PATH that are getting dropped when all you enter is “LD_LIBRARY_PATH=/opt/pgi/linux86-64/6.0/lib”. Also please add the “export” keyword in front of “PGI_JAVA=” and “LD_LIBRARY_PATH=” if you are using bash or sh for your shell. If you are using csh or tcsh, then add “setenv” in front of these (see below).
Sorry for not being clear, I had put continuation characters on the commands, so it’s the same effect as, say for example, passing environment variables into a configure command. My LD_LIBRARY_PATH variable is never set to anything anyway. Before posting, I’d actually been performing the same function as LD_LIBRARY_PATH with /etc/ld.so.conf, and was getting the same results, as well as when explicitly exporting the setting for PGI_JAVA.
I talked with another engineer here and it turns out we have seen this error before, but in another context. In addition to setting PGI_JAVA and LD_LIBRARY_PATH, try setting the following:
(bash/sh)
export LD_ASSUME_KERNEL=2.2.5
or
(csh/tcsh)
setenv LD_ASSUME_KERNEL 2.2.5
Also, what version of JAVA 1.5 did you install? Was it just the regular linux (32-bit) version? Or did you install the AMD-64 Opteron version of java 1.5? You’ll want to be using the 32-bit (regular linux) version of the Java JRE for PGPROF (and PGDBG).
If the LD_ASSUME_KERNEL=2.2.5 does not help and you are using the 32-bit version of java on linux, then verify that the file that the softlink /opt/pgi/linux86-64/6.0/lib/libpgthread.so links to exists on your system. We do find it a bit peculiar that java is looking for libpthread.so.0 in the PGI directory. There is a softlink called libpgthread.so that links to it, so maybe it’s looking there because there is no libpthread.so.0 on the system?
I had the 64 bit version installed. Once I installed the 32-bit version, it’s still no dice. I set the following
export PGI_JAVA=/usr/java/jre1.5.0_04-i586
export LD_LIBRARY_PATH=/opt/pgi/linux86-64/6.0/lib
[jevans@evans-temp srcS-pgi]$ pgprof -exe oceanS gmon.out
Warning: -Xmx512m not understood. Ignoring.
/usr/bin/gij: relocation error: /opt/pgi/linux86-64/6.0/lib/libpthread.so.0: symbol _h_errno, version GLIBC_2.2.5 not defined in file libc.so.6 with link time reference
I’m thinking that glibc is the problem here. There are actually two glibc rpms installed on this system, an i686 version and the x86_64 version. I believe that the i686 version is being picked up here, as the 32-bit version is missing the symbol referenced above. Running the strings command thru grep yields
Setting LD_ASSUME_KERNEL does bad things and results in an unusable terminal window, i.e.
export LD_ASSUME_KERNEL=2.2.5
pgprof -exe oceanS gmon.out
/bin/sh: error while loading shared libraries: libdl.so.2: cannot open shared object file: No such file or directory
Even adding the usual shared library paths back into the mix don’t correct this.
I checked the location of libpthread.so.0, and it looks right.
ls -al /opt/pgi/linux86-64/6.0/lib/libpgthread.so
lrwxrwxrwx 1 root root 22 Aug 18 09:30 /opt/pgi/linux86-64/6.0/lib/libpgthread.so → /lib64/libpthread.so.0
And /lib64/libpthread.so.0 does indeed exist, although it itself points to /lib64/libpthread-0.10.so
Have you had any luck running any other java applications on your system? I wonder if this is a problem with java in general on your system. Does PGDBG run?
Anyway, if you still cannot get things running, then send an email to tech support trs@pgroup.com and we’ll have you try some other things…