jpackage issue with --dest
Alexey Semenyuk
alexey.semenyuk at oracle.com
Wed Jun 16 20:12:44 UTC 2021
Hi Maurizio,
Thank you for the provided output.
According to the log, app launcher loaded libjli.so and it failed in
JLI_Launch() function.
Probably the problem is that you use jpackage from the build that has
https://bugs.openjdk.java.net/browse/JDK-8263157 fix that resulted in a
number of regressions fixed with
https://bugs.openjdk.java.net/browse/JDK-8267598 patch.
Chances are your local build doesn't contain a patch for JDK-8267598.
The latest jdk17 build at https://jdk.java.net/17/ contains patch for
JDK-8267598. Can you try it?
- Alexey
On 6/16/2021 1:52 PM, Maurizio Cimadamore wrote:
> This is what I get when I run jpackage:
>
> ```
> $ jpackage --type app-image --name HelloWorld --input
> /home/maurizio/Desktop/panama-test/jpackage-test/out/artifacts/jpackage_test_jar
> --main-jar jpackage-test.jar --dest bin
> [18:50:09.375]
> jpackage argument list:
> [--type, app-image, --name, HelloWorld, --input,
> /home/maurizio/Desktop/panama-test/jpackage-test/out/artifacts/jpackage_test_jar,
> --main-jar, jpackage-test.jar, --dest, bin]
>
> [18:50:09.409] Running dpkg
> [18:50:09.420] Command [PID: 399487]:
> dpkg --print-architecture
> [18:50:09.420] Output:
> amd64
> [18:50:09.422] Returned: 0
>
> [18:50:09.431] Creating app package: HelloWorld in /tmp/bin
> [18:50:13.288] Command [PID: -1]:
> jlink --output bin/HelloWorld/lib/runtime --module-path
> /w/lt/jdk/dev/build/linux-x86_64-server-release/images/jdk/jmods
> --add-modules
> jdk.management.jfr,java.rmi,jdk.jdi,jdk.charsets,jdk.xml.dom,java.xml,java.datatransfer,jdk.jstatd,jdk.httpserver,java.desktop,java.security.sasl,jdk.zipfs,java.base,jdk.crypto.ec,jdk.javadoc,jdk.management.agent,jdk.jshell,jdk.editpad,java.sql.rowset,jdk.sctp,jdk.jsobject,java.smartcardio,jdk.unsupported,jdk.jlink,java.security.jgss,java.compiler,jdk.nio.mapmode,jdk.dynalink,jdk.unsupported.desktop,jdk.accessibility,jdk.security.jgss,jdk.incubator.vector,java.sql,java.logging,java.transaction.xa,java.xml.crypto,jdk.jfr,jdk.crypto.cryptoki,jdk.random,jdk.net,java.naming,jdk.internal.ed,java.prefs,java.net.http,jdk.compiler,jdk.internal.opt,jdk.naming.rmi,jdk.jconsole,jdk.attach,jdk.internal.le,java.management,jdk.jdwp.agent,jdk.incubator.foreign,jdk.internal.jvmstat,java.instrument,jdk.management,jdk.security.auth,java.scripting,jdk.jdeps,jdk.jartool,java.management.rmi,jdk.jpackage,jdk.naming.dns,jdk.localedata
> --strip-native-commands --strip-debug --no-man-pages --no-header-files
> [18:50:13.288] Output:
> WARNING: Using incubator modules: jdk.incubator.foreign,
> jdk.incubator.vector
>
> [18:50:13.288] Returned: 0
>
> [18:50:13.292] Using default package resource JavaApp.png [icon] (add
> HelloWorld.png to the resource-dir to customize).
> [18:50:13.302] Succeeded in building Linux Application Image package
> ```
>
> And this is what happens when I run the generated binary:
>
> ```
> $ bin/HelloWorld/bin/HelloWorld
> popen: (rpm --queryformat '%{NAME}' -qf
> '/tmp/bin/HelloWorld/bin/HelloWorld' 2>/dev/null)
> popen: exit: 32512
> popen: (dpkg -S '/tmp/bin/HelloWorld/bin/HelloWorld' 2>/dev/null)
> popen: exit: 256
> [TRACE] app.cpp:123: Entering launch
> [TRACE] Executor.cpp:41: Reading output of [rpm --queryformat
> '%{NAME}' -qf '/tmp/bin/HelloWorld/bin/HelloWorld' 2>/dev/null] command
> [TRACE] Executor.cpp:41: Reading output of [dpkg -S
> '/tmp/bin/HelloWorld/bin/HelloWorld' 2>/dev/null] command
> [TRACE] LinuxLauncherLib.cpp:121: Set _JPACKAGE_LAUNCHER=[0]
> [TRACE] AppLauncher.cpp:99: Launcher config file path:
> "/tmp/bin/HelloWorld/lib/app/HelloWorld.cfg"
> [TRACE] JvmLauncher.cpp:43: Jvm(0x55a49cb86750)::Jvm()
> [TRACE] AppLauncher.cpp:71: Property "app.runtime" not found in
> "Application" section of launcher config file. Using Java runtime from
> "/tmp/bin/HelloWorld/lib/runtime" directory
> [TRACE] app.cpp:0: Exiting launch (entered at app.cpp:123)
> [TRACE] JvmLauncher.cpp:48: Jvm(0x55a49cb86750)::~Jvm()
> [TRACE] JvmLauncher.cpp:272: Need 310 bytes for JvmlLauncherData buffer
> [TRACE] JvmLauncher.cpp:272: Need 310 bytes for JvmlLauncherData buffer
> [TRACE] JvmLauncher.cpp:269: Initialized 310 bytes at 0x55a49cb86cc0
> address
> [TRACE] LinuxLauncherLib.cpp:157: unload
> jli lib: [/tmp/bin/HelloWorld/lib/runtime/lib/libjli.so]
> jli arg[0]: [/tmp/bin/HelloWorld/bin/HelloWorld]
> jli arg[1]: [-classpath]
> jli arg[2]: [/tmp/bin/HelloWorld/lib/app/jpackage-test.jar]
> jli arg[3]: [-Djpackage.app-version=1.0]
> jli arg[4]: [-Djpackage.app-path=/tmp/bin/HelloWorld/bin/HelloWorld]
> jli arg[5]: [main.Main]
> Error: could not find libjava.so
> Error: Could not find Java SE Runtime Environment.
> ```
>
> Does that clarify things?
>
> Thanks
> Maurizio
>
>
> On 16/06/2021 18:28, Alexey Semenyuk wrote:
>> Hi Maurizio,
>>
>> This is not known issue.
>> Can you run the app with "JPACKAGE_DEBUG" env variable set to "true".
>> In this case the app launcher will produce debug output that will
>> help to understand why it can't find libjava.so.
>>
>> - Alexey
>>
>> On 6/16/2021 9:11 AM, Maurizio Cimadamore wrote:
>>> Hi,
>>> I'm relatively new to jpackage and I found a weird issue on linux
>>> where the name of a --dest folder can affect the correct behavior of
>>> the generated application image.
>>>
>>> I have put together an hello world application, with a jarfile. If I
>>> jpackage it with the following command line:
>>>
>>> ```
>>> $ jpackage --type app-image --name HelloWorld --input
>>> out/artifacts/jpackage_test_jar --main-jar jpackage-test.jar --dest
>>> output
>>> ```
>>>
>>> Everything works correctly, and launching the generated app prints
>>> "Hello world":
>>>
>>> ```
>>> $ output/HelloWorld/bin/HelloWorld
>>> Hello world!
>>> ```
>>>
>>> However, if the destination directory contains "bin" (even as a
>>> nested subfolder), there are issues. Here's the jextract command line:
>>>
>>> ```
>>> $ jpackage --type app-image --name HelloWorld --input
>>> out/artifacts/jpackage_test_jar --main-jar jpackage-test.jar --dest bin
>>> ```
>>>
>>> (the only thihng that changed is the --dest parameter)
>>>
>>> And here's what I get:
>>>
>>> ```
>>> $ bin/HelloWorld/bin/HelloWorld
>>> Error: could not find libjava.so
>>> Error: Could not find Java SE Runtime Environment.
>>> ```
>>>
>>> I use Ubuntu 20.04. A colleague of mine using MacOS does not seem to
>>> have the same issue, so it seems to be system specific.
>>>
>>> I'm using the latest jpackage from jdk/jdk.
>>>
>>> Is this a known issue?
>>>
>>> Cheers
>>> Maurizio
>>>
>>
More information about the core-libs-dev
mailing list