I'm trying out java 9-ea (jdk-9+180) and the new javapackager to create a native image from a simple module but I get a nullpointer exception. Anyone know if I'm just too early or if I'm not using the right command switches in order to get it to work? The jlink command works fine but the javapackager does not. I'm using the latest jdk-9+180 at the time of writing. I have tried both with the -native exe and -native image switches but the same type of error occurs. I have also tried this on my Mac creating a native dmg with the -native dmg switch, but the same error occurs on that platform. I'm really after using the javapackager here to be able to bundle the build in exe/dmg.
Edit 1:
I have filed a bug report regarding this issue and it can now be visible at the following url: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8186661
My module-info.java:
module my.module {
requires javafx.graphics;
requires javafx.fxml;
exports sample;
}
First I'm creating a jar with javapackager which works fine:
C:\Java9Test\target>javapackager -createjar -appclass sample.Main -srcdir classes -outdir . -outfile myjar -v
I have verified the resulting jar structure looks okay with the correct compiled module-info.class and the other two classes in it.
The following jlink command works and produces a runnable reduced runtime image:
C:\Java9Test\target>jlink --output release\MyTestApp --compress=2 --module-path "myjar.jar;C:\Program Files\Java\jdk-9\jmods" --add-modules my.module
However, when trying the following command in order to create the native image using javapackager fails:
C:\Java9Test\target>javapackager -deploy -v -outdir packages -name MyTestApp -native image --module-path "myjar.jar;C:\Program Files\Java\jdk-9\jmods" --add-modules my.module --module my.module/sample.Main
outputs:
Running [C:\Program Files\Java\jdk-9\bin\java.exe, -version] Creating app bundle: MyTestApp in C:\Java9Test\target\packages Exception: java.lang.NullPointerException Exception in thread "main" com.sun.javafx.tools.packager.PackagerException: Error: Bundler "Windows Application Image" (windows.app) failed to produce a bundle. at jdk.packager/com.sun.javafx.tools.packager.PackagerLib.generateNativeBundles(PackagerLib.java:374) at jdk.packager/com.sun.javafx.tools.packager.PackagerLib.generateDeploymentPackages(PackagerLib.java:348) at jdk.packager/com.sun.javafx.tools.packager.Main.main(Main.java:496)
Edit 2:
Output from -native exe flag (on Windows)
Running [C:\Program Files\Java\jdk-9\bin\java.exe, -version]
Running [C:\Program Files (x86)\Inno Setup 5\iscc.exe, /?]
Detected [C:\Program Files (x86)\Inno Setup 5\iscc.exe] version [5]
At least one type of shortcut is required. Enabling menu shortcut.
Exception: java.lang.NullPointerException
Config files are saved to C:\Users\Username\AppData\Local\Temp\fxbundler17330843784617821035\windows. Use them to customize package.
Exception in thread "main" com.sun.javafx.tools.packager.PackagerException: Error: Bundler "EXE Installer" (exe) failed to produce a bundle.
at jdk.packager/com.sun.javafx.tools.packager.PackagerLib.generateNativeBundles(PackagerLib.java:374)
at jdk.packager/com.sun.javafx.tools.packager.PackagerLib.generateDeploymentPackages(PackagerLib.java:348)
at jdk.packager/com.sun.javafx.tools.packager.Main.main(Main.java:496)
Edit 3:
Output from -native dmg flag (on MacOSX)
Building DMG package for MyTestApp
Exception: java.lang.NullPointerException
Config files are saved to /var/folders/qs/nk3vxsx90q9_pbjs0ypg74r40000gn/T/fxbundler3765252041328710759/macosx. Use them to customize package.
Exception in thread "main" com.sun.javafx.tools.packager.PackagerException: Error: Bundler "DMG Installer" (dmg) failed to produce a bundle.
at jdk.packager/com.sun.javafx.tools.packager.PackagerLib.generateNativeBundles(PackagerLib.java:374)
at jdk.packager/com.sun.javafx.tools.packager.PackagerLib.generateDeploymentPackages(PackagerLib.java:348)
at jdk.packager/com.sun.javafx.tools.packager.Main.main(Main.java:496)
Output from -native deb flag (on Linux Mint)
Running [dpkg-deb, --version]
Debian packages should specify a license. The absence of a license will cause some linux distributions to complain about the quality of the application.
Exception: java.lang.NullPointerException
Config files are saved to /tmp/fxbundler2941553392593775128/linux. Use them to customize package.
Exception in thread "main" com.sun.javafx.tools.packager.PackagerException: Error: Bundler "DEB Installer" (deb) failed to produce a bundle.
at jdk.packager/com.sun.javafx.tools.packager.PackagerLib.generateNativeBundles(PackagerLib.java:374)
at jdk.packager/com.sun.javafx.tools.packager.PackagerLib.generateDeploymentPackages(PackagerLib.java:348)
at jdk.packager/com.sun.javafx.tools.packager.Main.main(Main.java:496)
Output from -native rpm flag (on Linux Mint)
Running [rpmbuild, --version]
At least one type of shortcut is required. Enabling menu shortcut.
Exception: java.lang.NullPointerException
Config files are saved to /tmp/fxbundler2278571164448075269/linux. Use them to customize package.
Exception in thread "main" com.sun.javafx.tools.packager.PackagerException: Error: Bundler "RPM Bundle" (rpm) failed to produce a bundle.
at jdk.packager/com.sun.javafx.tools.packager.PackagerLib.generateNativeBundles(PackagerLib.java:374)
at jdk.packager/com.sun.javafx.tools.packager.PackagerLib.generateDeploymentPackages(PackagerLib.java:348)
at jdk.packager/com.sun.javafx.tools.packager.Main.main(Main.java:496)
Answering my own question here (after having received a reply on the bug-report):
It turns out that the module-path must contain only directory names, not file names, hence you can not specify the jar in the path as you can with the jlink command. The javapackager works with the module-path if set to the compiled module-classes like below, also you don't need to put in the module-path to the jmods directory because it is picked up automatically.
C:\Java9Test\target>javapackager -deploy -v -outdir packages -name MyTestApp -native image --module-path C:\Java9Test\target\classes --module my.module/sample.Main
However, the resulting build's executable MyTestApp.exe did not work for me, nothing happened when invoked (double-clicked). Also the build is quite bulky and it seems you can not use the --compress=2 and --strip-debug flags yet as you can with jlink. However, I discovered that you can actually replace the content of the runtime folder produced with the javapackager with the output from the jlink command giving the build a much smaller footprint and the MyTestApp.exe works when invoked! I could also delete the java.exe and javaw.exe from the replaced runtime\bin folder as well as the msvcp120.dll and msvcr120.dll from the main MyTestApp-folder since those dll:s are already in the MyTestApp\runtime\bin folder.
MyTestApp-folder structure:
.
Related
If want to run dotnet-trace on Linux, against an application that ships with its own .NET Core runtime. When I run it, however, I get:
A fatal error occurred. The required library libhostfxr.so could not be found.
If this is a self-contained application, that library should exist in [/home/user/.net/dotnet-trace/RMBGJOBRwpkX5Kvpq_FShF5s1UmJMO8=/].
If this is a framework-dependent application, install the runtime in the global location [/usr/share/dotnet] or use the DOTNET_ROOT environment variable to specify the runtime location or register the runtime location in [/etc/dotnet/install_location].
I located the libhostfxr.so library at /home/user/app/libhostfxr.so, then executed DOTNET_ROOT=/home/user/app/ dotnet-trace, but got the same error.
How do I go from the path of this library to the correct setting for DOTNET_ROOT?
According to strace, it is looking for the file /home/user/app/host/fxr which does not exist.
I ended up installing the .NET version that matched the application I was trying to debug using the install script. (I found this by using strings libhostfxr.so; perhaps there's a better way.)
A little confusingly, the runtime version 3.1.28 is not the same as the corresponding SDK version 3.1.422, which I installed with:
$ wget -O - https://dot.net/v1/dotnet-install.sh | bash /dev/stdin --version 3.1.422
It can also be downloaded from versionsof.net which is not an official site, but it links to the files hosted by Microsoft.
This process installed /home/user/.dotnet/host/fxr/3.1.28/libhostfxr.so and I could then run DOTNET_ROOT=/home/user/.dotnet/ dotnet-trace.
I'm getting the following error message when I run a program that uses Poco::NetSSL:
error while loading shared libraries: libPocoCryptod.so.81: cannot
open shared object file: No such file or directory
Here is my CMakeLists.txt:
cmake_minimum_required(VERSION 3.16)
set(PROJECT_NAME "pocotest")
project(${PROJECT_NAME})
find_package(Poco REQUIRED DataMySQL Net NetSSL)
add_executable(${PROJECT_NAME} src/PocoTest.cpp)
target_link_libraries(${PROJECT_NAME} PUBLIC Poco::Net Poco::NetSSL)
I installed Poco libraries from source, making sure to enable NetSSL. If I ls /usr/local/lib, the file libPocoCrypto.so.81 is there. I don't know what's missing here.
You appear to be linking with the debug version rather than the release version. Your error is for the "d" version of the file, "libPocoCryptod.so.81". But your file is the release version "libPocoCrypto.so.81"
I just needed to run sudo ldconfig on Ubuntu.
I'm installing dotnet core on Linux ARM64 using tarball as explained here. After installing I followed the suggestion to set DOTNET_ROOT=$PATH:$HOME/dotnet. However global tools fail with A fatal error occurred, the required library libhostfxr.so could not be found.
I fixed by changing the env variable to DOTNET_ROOT=$HOME/dotnet.
Is this a bug in the docs ?
Yes, this appears to be a bug in the documentation. The code which interprets DOTNET_ROOT does not split the string on :. DOTNET_ROOT should be set to an absolute file path which points to the directory containing the dotnet executable. If dotnet is on your PATH already, you can set it like this in bash/zsh.
export DOTNET_ROOT="$(dirname $(which dotnet))"
came across this problem while working on porting .net libraries from Windows to Raspberry PI. On the Raspberry the .net core 3.1 installs in /opt/dotnet, and that's where DOTNET_ROOT ought to point at:
export DOTNET_ROOT="/opt/dotnet"
This should eliminate the "fatal error occurred. The required library libhostfxr.so could not be found." error when attempting to run portable code using the 'dotnet' command on the RPI
I was getting an error trying to execute the dotnet ef from the EF cli global tools install.
Added this to the bottom of my /home/<user>/.bashrc worked for me.
# User specific aliases and functions
export DOTNET_ROOT=$HOME/.dotnet
export PATH=$PATH:$DOTNET_ROOT:$DOTNET_ROOT/tools
Then the dotnet ef command worked correctly.
I had to add this to my ~/.zshrc
export DOTNET_ROOT=~/.dotnet
export PATH=$PATH:$DOTNET_ROOT
I found that I had different locations for different sdk/runtime versions. One was installed at "/home/{username}/.dotnet" and the other at "/usr/share/dotnet".
I found a post stating the default DOTNET_ROOT is "/usr/share/dotnet" and errors showed dotnet command was executing this location. I copied all files from "home/{username}/.dotnet" to "/usr/share/dotnet" with rsync.
sudo apt install rsync;
sudo rsync -a /home/{username}/.dotnet/ /usr/share/dotnet
I have just started to experiment with Zephir over the weekend, and had managed to compile and run a hello world extension on the mac terminal. I have AMPPS installed, and am trying to install this extension on AMPPS. Not sure if my steps are correct, but if I copied the .so file over, I get this error from AMPPS:
Warning: PHP Startup: Unable to load dynamic library '/Applications/AMPPS/php-7.1/lib/extensions/ext/utils.so' - dlopen(/Applications/AMPPS/php-7.1/lib/extensions/ext/utils.so, 9): no suitable image found. Did find: /Applications/AMPPS/php-7.1/lib/extensions/ext/utils.so: mach-o, but wrong architecture /Applications/AMPPS/php-7.1/lib/extensions/ext/utils.so: stat() failed with errno=3 in Unknown on line 07.1.2
What is the correct way to install the compiled extensions on hosted servers in future?
The ERROR was obvious ： Unable to load dynamic library '/Applications/AMPPS/php-7.1/lib/extensions/ext/utils.so' . That may mean your .so lib was not found. Maybe you past your extension lib file into an incorrect path.
So you can try to type php -i | grep extension in your terminal.
And it will output your extension path like extension_dir => /usr/local/lib/php/extensions/no-debug-non-zts-20151012 => /usr/local/lib/php/extensions/no-debug-non-zts-20151012.
Check your extension exist or not in this direction.
BTW you can using command php -m to check how many extensions you have installed .
I am creating a simple Alljoyn java application to send and respond to a few signals. When I run the code in Eclipse (on Win7) it runs fine. However when I export it as a runnable jar file and attempt to run that I get the following error
Exception in thread "main" java.lang.UnsatisfiedLinkError: no alljoyn_java in java.library.path
The exception is triggered upon calling executing the following code:
static { System.loadLibrary("alljoyn_java");}
I have configured the build path of the project to use the external jar alljoyn_java and set the Native library location of that library to the parent directory of the alljoyn_java.dll file.
You have to place the files alljoyn_java.dll, alljoyn_java.lib and alljoyn_java.exp in the same directory of the jar file.
Then, run the jar with the following command:
java -jar -Djava.library.path=. [your-jar-file.jar]
The JVM looks for native libraries at path specified in java.library.path (as mentioned in answer above) and/or path specified in environment variable LD_LIBRARY_PATH. Either use the command mentioned in comment above or add path of directory containing your library to environment variable LD_LIBRARY_PATH.
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:<<path_of_dir_containing_lib>>
java -jar <<your_jar_file>>
So what I ended up doing is downloading jarsplice and using that to add the native libraries after I exported the project from Eclipse as a .jar