jpackage issue with --dest
Maurizio Cimadamore
maurizio.cimadamore at oracle.com
Wed Jun 16 17:52:17 UTC 2021
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