Link to home
Start Free TrialLog in
Avatar of Seydina Fall
Seydina Fall

asked on

java -version command not working on AIX 6.1 (JRE version installed is 1.7)

Hello,
I am getting the following error while trying to executing the java -version command :
libjvm.so preloadLibrary(/usr/openv/java/sdk/jre/lib/ppc64/compressedrefs/libj9vm27.so): Symbol resolution failed for /usr/openv/java/sdk/jre/lib/ppc64/compressedrefs/libj9prt27.so because:
        Symbol getsystemcfg (number 162) is not exported from dependent
          module /usr/lib/libc.a[shr_64.o].
Could not load module /usr/openv/java/sdk/jre/lib/ppc64/compressedrefs/libj9vm27.so.
System error: Exec format error
Examine .loader section symbols with the 'dump -Tv' command.
libjvm.so failed to load: j9vm27

The oslevel command give this :
<user>-/usr/java71_64/jre/bin> oslevel -s
6100-03-01-0921

All libraries seem to be present.
Can you help to resolve the problem ?

Thanks
Avatar of John Pope
John Pope
Flag of United Kingdom of Great Britain and Northern Ireland image

Hi

Possibly you have more than one version of java installed, so check the installed version;

lslpp -L "Java*"

You could also check your environment settings for $PATH or $JAVA_HOME

We have the
/usr/<javaversion>/jre/bin

Open in new window

and
/usr/<javaversion>/bin

Open in new window

in our path.  We also have multiple versions installed.

Cheers, JP.
SOLUTION
Avatar of woolmilkporc
woolmilkporc
Flag of Germany image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of Seydina Fall
Seydina Fall

ASKER

I have two java versions installed :

hintihra-/usr/java71_64/jre/bin> lslpp -L "Java*"
  Fileset                      Level  State  Type  Description (Uninstaller)
  ----------------------------------------------------------------------------
  Java5.sdk                5.0.0.225    C     F    Java SDK 32-bit
  Java5_64.sdk             5.0.0.225    C     F    Java SDK 64-bit
  Java6_64.sdk             6.0.0.406    C     F    Java SDK 64-bit

But my goal is to install the jre1.7 needed by a single important application.
So I'll customize the profile of the user which for the application to point to the to java 1.7.

The installation of 1.7 was aborted because below filesets are available on server with lower version as TL level is low :
    X11.base.lib 6.1.7.0                      # Base Level Fileset
    X11.base.rte 6.1.7.0                      # Base Level Fileset
    X11.motif.mwm 6.1.7.0                     # Base Level Fileset
    bos.mp64 6.1.7.0                          # Base Level Fileset
    bos.net.tcp.client 6.1.7.0                # Base Level Fileset
    bos.rte 6.1.7.0                           # Base Level Fileset
    bos.rte.libc 6.1.7.0                      # Base Level Fileset
    bos.rte.libpthreads 6.1.7.0               # Base Level Fileset

To install java 1.7, I need to upgrade the level from 3 to 5 TL and I can't right now because others many applications are running in the server.

So after this issue I copied the directory /usr/java71_64 from another AIX server with good level and restored it in my server in order to fix the issue, I'am getting the error.

Here are my java environment variables :
hintihra-/usr/java71_64/jre/bin> echo $JAVACMD
/usr/java71_64/jre/bin/java
hintihra-/usr/java71_64/jre/bin> echo $JAVA_HOME
/usr/java71_64/jre

So can you help to circumvent the problem ?

Thanks
ASKER CERTIFIED SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Hi

Just to press home the point that WMP is right.

Merely copying a directory over from a more recent OS level server to the one you want to upgrade can't account for the aforementioned dependencies.

Cheers, JP.
The answer https:#a40449587 contains a valid explanation of the problem the asker is/was facing.
Dependencies like the one in question here between the OS level and the supported Java versions can always be found on the IBM Webpage whose link was posted in https:#a40449555 (yes, it's still valid!).

See also popesy's confirmation that just copying programs over from higher-level servers will hardly ever remedy such issues.

Suggestion: Split between https:#a40449555 and https:#a40449587.