jre/lib/s390x/compressedrefs/libjvm.so missing libdl reference

[nealef]

Platform:
Linux

Architecture:
s390x

The libjvm.so found in the java-8 compressedrefs directory doesn't reference libdl so that linking against it results in unresolved references to things like dlopen. Adding -ldl circumvents this but the other libjvm.so that are part of the tarball have been linked against the library:

$ ldd jre/lib/s390x/compressedrefs/libjvm.so
	libpthread.so.0 => /lib/s390x-linux-gnu/libpthread.so.0 (0x000003ff93880000)
	libm.so.6 => /lib/s390x-linux-gnu/libm.so.6 (0x000003ff93780000)
	libc.so.6 => /lib/s390x-linux-gnu/libc.so.6 (0x000003ff93580000)
	/lib/ld64.so.1 (0x000003ff93a00000)

$ nm jre/lib/s390x/compressedrefs/libjvm.so | grep dlopen
                 U dlopen

$ ldd jre/lib/s390x/j9vm/libjvm.so
	libdl.so.2 => /lib/s390x-linux-gnu/libdl.so.2 (0x000003ff9ec00000)
	libm.so.6 => /lib/s390x-linux-gnu/libm.so.6 (0x000003ff9eb00000)
	libc.so.6 => /lib/s390x-linux-gnu/libc.so.6 (0x000003ff9e900000)
	/lib/ld64.so.1 (0x000003ff9ed80000)

$ nm jre/lib/s390x/j9vm/libjvm.so | grep dlopen
                 U dlopen@@GLIBC_2.2

Is there a reason for this difference? Although it can be circumvented building packages like hadoop requires changes to the canonical sources which is never a great thing to have to do and doesn't happen when using the standard java-1.8.0-openjdk that comes with the distros.

[karianna]

@nealef Can you give us the output of java --version?

[nealef]

OpenJDK Runtime Environment (build 1.8.0_222-b10)
Eclipse OpenJ9 VM (build openj9-0.15.1, JRE 1.8.0 Linux s390x-64-Bit Compressed References 20190717_371 (JIT enabled, AOT enabled)
OpenJ9   - 0f66c6431
OMR      - ec782f26
JCL      - f147086df1 based on jdk8u222-b10)

[keithc-ca]

jre/lib/s390x/compressedrefs/libjvm.so is an implementation detail of OpenJ9. You should be linking against one of these:

jre/lib/s390x/server/libjvm.so
jre/lib/s390x/j9vm/libjvm.so

both of which reference libdl.so:

$ ldd jre/lib/s390x/server/libjvm.so jre/lib/s390x/j9vm/libjvm.so
j9vm/libjvm.so:
	libdl.so.2 => /lib/s390x-linux-gnu/libdl.so.2 (0x000003ff9e800000)
	libm.so.6 => /lib/s390x-linux-gnu/libm.so.6 (0x000003ff9e700000)
	libc.so.6 => /lib/s390x-linux-gnu/libc.so.6 (0x000003ff9e500000)
	/lib/ld64.so.1 (0x000003ff9e980000)
server/libjvm.so:
	libdl.so.2 => /lib/s390x-linux-gnu/libdl.so.2 (0x000003ffbc600000)
	libm.so.6 => /lib/s390x-linux-gnu/libm.so.6 (0x000003ffbc500000)
	libc.so.6 => /lib/s390x-linux-gnu/libc.so.6 (0x000003ffbc300000)
	/lib/ld64.so.1 (0x000003ffbc780000)

[nealef]

True, but unfortunately tools like cmake's find_library() macro will find it ahead of the others. So building things like hadoop 3.2.0 will be problematic against the openj9 variant.

[keithc-ca]

I suggest that is a bug in cmake.

[nealef]

It can be coded around in a cmake receipt by specifying the search order. However, what I had liked about Adopt openjdk was that it didn't matter if you were using hotspot or openj9 things would just work. Now we have to add exceptions in existing package builds to use it. That means generating PRs that maintainers may or may not want to apply. Does the compressedrefs/libjvm.so have to live in jre/lib/<arch>/ part of the tree? Does it have to have that exact name?

[keithc-ca]

eclipse-openj9/openj9#7355 proposes that it be renamed.

[nealef]

Perfect! Thank you so much.

[sxa]

Problems have been found trying to do this across platforms as per eclipse-openj9/openj9#7380 (comment) so this fix is still on hold

[github-actions]

We are marking this issue as stale because it has not been updated for a while. This is just a way to keep the support issues queue manageable.
It will be closed soon unless the stale label is removed by a committer, or a new comment is made.

[karianna]

Still open upstream

[github-actions]

We are marking this issue as stale because it has not been updated for a while. This is just a way to keep the support issues queue manageable.
It will be closed soon unless the stale label is removed by a committer, or a new comment is made.

[karianna]

Still open upstream

[github-actions]

We are marking this issue as stale because it has not been updated for a while. This is just a way to keep the support issues queue manageable.
It will be closed soon unless the stale label is removed by a committer, or a new comment is made.

[karianna]

As this has been reported upstream I'm closing this issue