Custom jlink images and dynamically linked shared libraries

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Custom jlink images and dynamically linked shared libraries

Severin Gehwolf
Hi,

It appears to be that jlink-produced custom images rely on the fact
that jmods in the module-path have been produced with static linking
and bundled libraries. This assumption might not always hold for
downstream builders.

Since JDK 9+ there are build options to use system lcms, system jpeg,
system gif libs etc. Example:

$ bash configure [...]--with-libpng=system

If a build was produced in such a way, the resulting image would then
depend on a similar (if not same) system libpng than the host on which
the original JDK - used for the module-path - has been built.

Some background info is here:
https://bugzilla.redhat.com/show_bug.cgi?id=1659192

Has this been considered at all? Am I wrong in thinking that the
canonical answer for this is: Don't build the JDK that way

Thanks,
Severin

Reply | Threaded
Open this post in threaded view
|

Re: Custom jlink images and dynamically linked shared libraries

Alan Bateman
On 17/12/2018 08:38, Severin Gehwolf wrote:

> Hi,
>
> It appears to be that jlink-produced custom images rely on the fact
> that jmods in the module-path have been produced with static linking
> and bundled libraries. This assumption might not always hold for
> downstream builders.
>
> Since JDK 9+ there are build options to use system lcms, system jpeg,
> system gif libs etc. Example:
>
> $ bash configure [...]--with-libpng=system
>
> If a build was produced in such a way, the resulting image would then
> depend on a similar (if not same) system libpng than the host on which
> the original JDK - used for the module-path - has been built.
>
> Some background info is here:
> https://bugzilla.redhat.com/show_bug.cgi?id=1659192
>
> Has this been considered at all? Am I wrong in thinking that the
> canonical answer for this is: Don't build the JDK that way
>
jlink doesn't run `ldd` or equivalent to find the shared objects that
native libraries in a packaged module might depend on. It could, as a
plugin perhaps, to identify that the system doesn't have the required
libraries. This won't work of course for cases where you generate the
run-time image on one system and then copy it to another system that
doesn't have the libraries.

-Alan