PR#28: Warn about distribution specific jlink-produced images. - rpms/java-11-openjdk

rpms / java-11-openjdk

#28 Warn about distribution specific jlink-produced images.

Closed 3 years ago by jvanek. Opened 5 years ago by jerboaa.

rpms/ jerboaa/java-11-openjdk master-jlink-distro-specific-image into master

Warn about distribution specific jlink-produced images.

Severin Gehwolf • 5 years ago

9521017

java-11-openjdk.spec

file modified

+11 -1

		`@@ -956,7 +956,7 @@`

		`Name: java-%{javaver}-%{origin}`
		`Version: %{newjavaver}.%{buildver}`
		`- Release: 10%{?dist}`
		`+ Release: 11%{?dist}`
		`# java-1.5.0-ibm from jpackage.org set Epoch to 1 for unknown reasons`
		`# and this change was brought into RHEL-4. java-1.5.0-ibm packages`
		`# also included the epoch in their virtual provides. This created a`
		`@@ -1028,6 +1028,9 @@`
		`Patch4: pr3183-rh1340845-support_fedora_rhel_system_crypto_policy.patch`
		`# System NSS via SunEC Provider`
		`Patch5: pr1983-rh1565658-support_using_the_system_installation_of_nss_with_the_sunec_provider_jdk11.patch`
		`+ # jlink warning for distribution specific build`
		`+ Patch20: rh1659192-jlink_warning_distro_specific_image.patch`
		`+`

		`#############################################`
		`#`
		`@@ -1341,6 +1344,7 @@`
		`%patch10 -p1`
		`%patch11 -p1`
		`%patch12 -p1`
		`+ %patch20 -p1`
		`%patch584 -p1`
		`%patch585 -p1`
		`popd # openjdk`
		`@@ -1893,6 +1897,12 @@`


		`%changelog`
		`+ * Fri Dec 14 2018 Severin Gehwolf <sgehwolf@redhat.com> - 1:11.0.1.13-11`
		`+ - Warn about distribution specific builds when jlink is being used`
		`+ without specifying a module-path. See RHBZ#1659192`
		`+ - Added distribution specific patch,`
		`+ rh1659192-jlink_warning_distro_specific_image.patch`
		`+`
		`* Wed Dec 5 2018 Jiri Vanek <jvanek@redhat.com> - 1:11.0.1.13-9`
		`- for non debug supackages, ghosted all masters and slaves (rhbz1649776)`
		`- for tech-preview packages, if-outed versionless provides. Aligned versions to be %%{epoch}:%%{version}-%%{release} instead of chaotic`

rh1659192-jlink_warning_distro_specific_image.patch

file added

+39

		`@@ -0,0 +1,39 @@`
		`+ # HG changeset patch`
		`+ # User sgehwolf`
		`+ # Date 1546506134 -3600`
		`+ # Thu Jan 03 10:02:14 2019 +0100`
		`+ # Node ID 606f63c205695d16502de6b8ba4c1b4f5ec39bf9`
		`+ # Parent bda6414e933c9274f59184ece7c4b15283d70dac`
		`+ Add warning about distribution specific build.`
		`+ Reviewed-by: jvanek`
		`+`
		`+ diff --git a/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java b/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java`
		`+ --- a/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java`
		`+ +++ b/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java`
		`+ @@ -256,6 +256,10 @@`
		`+ // no --module-path specified - try to set $JAVA_HOME/jmods if that exists`
		`+ Path jmods = getDefaultModulePath();`
		`+ if (jmods != null) {`
		`+ + // When no module path is being specified at the command line`
		`+ + // we know for distribution builds that jlink-created images`
		`+ + // will also be distro specific.`
		`+ + System.err.println(taskHelper.getMessage("warn.image.distro.specific"));`
		`+ options.modulePath.add(jmods);`
		`+ }`
		`+`
		`+ diff --git a/src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties b/src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties`
		`+ --- a/src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties`
		`+ +++ b/src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties`
		`+ @@ -144,6 +144,12 @@`
		`+ warn.invalid.arg=invalid classname or pathname not exist: {0}`
		`+ warn.split.package=package {0} defined in {1} {2}`
		`+ warn.provider.notfound=No provider found for service specified to --suggest-providers: {0}`
		`+ +warn.image.distro.specific=WARNING: This JDK image is dynamically linked. This means the JDK you are using as \`
		`+ +basis for a custom image is very likely distribution specific. Therefore, the resulting image will most likely run \`
		`+ +only on this distribution too. In order to avoid this issue, \`
		`+ +please download a staticly linked JDK, and use that for the module path. \`
		`+ +In addition, there can be issues with the size of native libraries and executables. \`
		`+ +If your image seems excessive in size, consider using option ''--native-libs-replace''.`
		`+ no.suggested.providers=--bind-services option is specified. No additional providers suggested.`
		`+ suggested.providers.header=Suggested providers`
		`+ providers.header=Providers`

jerboaa commented 5 years ago

When no module path is being specified on the command line,
the default module path is being used which is ${java.home}/jmods.
This implies that distribution specific libraries are being
transferred to the custom image, which, in turn, will be
distribution specific too. Warn about this in jlink.

See RHBZ#1659192

jvanek commented 5 years ago

Can the hint suggest --native-libs-replace and varn about dynamic linking?

jerboaa commented 5 years ago

Can the hint suggest --native-libs-replace and varn about dynamic linking?

What exactly is the suggested wording?

jvanek commented 5 years ago

Maybe better solution - which can be upstreamed - if the jdk is build as dynamic, to recognize it, and include the warning. When it is static, then not.

WARNING: JDK images are dynamically linked. Most likely they are distribution specific. This can have several consequences. Your resulting image will most likely run on this distribution compatible systems only. To avoid this issue, please download static builds form https://adoptopenjdk.net/ (note RPM patch should point to developer.redhat.com) In addition, there can be issue with debug symbols in native code. If your images are to larg,e and you do not wish to debug native parts, then use --native-libs-replace plugin.

jerboaa commented 5 years ago

In addition, there can be issue with debug symbols in native code. If your images are too large and you do not wish to debug native parts, then use --native-libs-replace plugin.

Debugging native libraries will still work with --native-libs-replace. Even dnf debuginfo-install <foo> will work as expected. So that's not correct. See:
https://bugzilla.redhat.com/show_bug.cgi?id=1652177#c7

jerboaa commented 5 years ago

Maybe better solution - which can be upstreamed - if the jdk is build as dynamic, to recognize it, and include the warning. When it is static, then not.

Probably. It would be a matter of detecting this at runtime for each shared library. Even so, some libs might be OK (glibc?) whereas others might not (lcms, jpeg, png libs etc.) You don't really know ahead of time. Suggestions welcome as to how to do this.

jvanek commented 5 years ago

I was more based on build time, where clear parameter of --with-stdc++lib=dynamic pass in.

jvanek commented 5 years ago

(and with png==system, jpg=system and friends.) but maybe it is to detailed.

rebased onto 9521017

5 years ago

jerboaa commented 5 years ago

I've updated this with a more verbose warning:

WARNING: This JDK image is dynamically linked. This means the JDK you are using as basis for a custom image is very likely distribution specific. Therefore, the resulting image will most likely run only on this distribution too. In order to avoid this issue, please download a staticly linked JDK, and use that for the module path. In addition, there can be issues with the size of native libraries and executables. If your image seems excessive in size, consider using option '--native-libs-replace'.

Detecting dynamic linking at build time and then conditionally producing this warning seems overkill. We can reasonably say that our distro builds are dynamically linked without special detection.