Closed pshipton closed 4 years ago
I assume this was tested with the GA version? This should no longer the the case (e.g. in recent builds such as those from https://ci.adoptopenjdk.net/job/build-scripts/job/jobs/job/jdk13u/job/jdk13u-aix-ppc64-hotspot/) as we switched back to using the original build boxes for JDK13 instead of the TL5SP5 ones.
I assume this was tested with the GA version?
Yes, I was looking at the OpenJ9 releases. Looking at the link you provided I see the following, which is good.
0 /opt/IBM/xlc/16.1.0/../../../../usr/lpp/xlC/lib:/opt/IBM/xlC/16.1.0/lib/aix61:/opt/IBM/xlC/16.1.0/lib:/opt/IBM/xlc/16.1.0/lib/aix61:/opt/IBM/xlc/16.1.0/lib:/usr/vac/lib/aix53:/usr/lib:/lib
@sxa this is the old issue I mentioned, which may be occurring with the builds on the AIX TL5 SP5 machine.
Looks like the new builds do include java8 in the embedded LIBPATH
The versions on the OpenJ9 CI from https://ci.eclipse.org/openj9/job/Build_JDK14_ppc64_aix_Nightly appear to have the same issue
I think this is a side effect of the IBM JVM being used to run the jenkins agent on that machine - will switch it over to an adoptopenjdk one ...
will switch it over to an adoptopenjdk one
Won't that just change the LIBPATH to include a different version of Java? It would be better to set the LIBPATH to remove any Java before running the JDK build.
I was under the impression it didn't happen with the HotSpot implementations although a couple of additional tests I'm doing today suggests that isn't the case. I'll keep looking at it
Java paths are no longer in the embedded library search path:
-bash-4.3$ find . -name libjava.so | while read a; do echo ===== $a; dump -X64 -Hp $a | grep ^0\ ; done===== ./jdk-11.0.8+4-jre/lib/libjava.so
0 /opt/IBM/xlc/13.1.3/../../../../usr/lpp/xlC/lib:/opt/IBM/xlC/13.1.3/lib/aix61:/opt/IBM/xlC/13.1.3/lib:/opt/IBM/xlc/13.1.3/lib/aix61:/opt/IBM/xlc/13.1.3/lib:/usr/vac/lib/aix53:/opt/freeware/lib:/usr/lib
===== ./jdk-14.0.1+7-jre/lib/libjava.so
0 /opt/IBM/xlc/16.1.0/../../../../usr/lpp/xlC/lib:/opt/IBM/xlC/16.1.0/lib/aix61:/opt/IBM/xlC/16.1.0/lib:/opt/IBM/xlc/16.1.0/lib/aix61:/opt/IBM/xlc/16.1.0/lib:/usr/vac/lib/aix53:/usr/lib:/lib
===== ./jdk8u262-b03-jre/lib/ppc64/libjava.so
0 /opt/IBM/xlc/13.1.3/../../../../usr/lpp/xlC/lib:/opt/IBM/xlC/13.1.3/lib/aix61:/opt/IBM/xlC/13.1.3/lib:/opt/IBM/xlc/13.1.3/lib/aix61:/opt/IBM/xlc/13.1.3/lib:/usr/vac/lib/aix53:/opt/freeware/lib:/usr/lib
-bash-4.3$
Platform: AIX
The Java builds (both Hotspot and OpenJ9) are setup to embed the current LIBPATH setting into the header section of Java shared libraries and executables created.
As seen via
dump -X64 -Hp <file>
, looking at an OpenJ9 build, for Java 8 and 11 the embedded path is as follows, which is acceptable:0 /opt/IBM/xlc/13.1.3/../../../../usr/lpp/xlC/lib:/opt/IBM/xlC/13.1.3/lib/aix61:/opt/IBM/xlC/13.1.3/lib:/opt/IBM/xlc/13.1.3/lib/aix61:/opt/IBM/xlc/13.1.3/lib:/usr/vac/lib/aix53:/usr/lib:/lib
For Java 13+ the embedded path is as follows. I'm not aware of any actual problems caused by this, but it seems wrong to have Java 8 directories on the default search path when running a different version of Java.
0 /opt/IBM/xlc/16.1.0/../../../../usr/lpp/xlC/lib:/opt/IBM/xlC/16.1.0/lib/aix61:/opt/IBM/xlC/16.1.0/lib:/opt/IBM/xlc/16.1.0/lib/aix61:/opt/IBM/xlc/16.1.0/lib:/usr/vac/lib/aix53:/opt/freeware/lib:/usr/java8_64/jre/lib/ppc64/j9vm:/usr/java8_64/jre/lib/ppc64:/usr/java8_64/jre/../lib/ppc64:/usr/java8_64/jre/lib/icc:/usr/lib
It causes
ldd
to indicate libraries will be loaded from the wrong place (/usr/java8_64), and as a side affect shows extra prereqs (libdbgwrapper80.so) although this isn't what happens when you run Java.