Java load native library linux

There are several ways to make it possible for the Java runtime to find and load a native shared library (.so) at runtime. I will list them briefly here, followed by examples with more explanation below.

Call System.load to load the .so from an explicitly specified absolute path.
Copy the shared library to one of the paths already listed in java.library.path
Modify the LD_LIBRARY_PATH environment variable to include the directory where the shared library is located.
Specify the java.library.path on the command line by using the -D option.

Note: To help resolve an UnsatisfiedLinkError Runtime Error, see How to Handle the UnsatisfiedLinkError Runtime Error in Java

Читайте также: Php ini get memory limit

1. Call System.load to load the shared library from an explicitly specified absolute path.

This choice removes all uncertainty, but embeds a hard-coded path within your Java application. Example:

import com.chilkatsoft.CkZip; public class Test < static < try < System.load("/home/joe/chilkatJava/libchilkat.so"); > catch (UnsatisfiedLinkError e) < System.err.println("Native code library failed to load.\n" + e); System.exit(1); >> public static void main(String argv[]) < CkZip zip = new CkZip(); System.out.println(zip.version()); >>

2. Copy the shared library to one of the paths already listed in java.library.path

To view the paths listed in java.library.path, run this Java code:

String property = System.getProperty(«java.library.path»); StringTokenizer parser = new StringTokenizer(property, «;»); while (parser.hasMoreTokens())

Note: The java.library.path is initialized from the LD_LIBRARY_PATH environment variable.

The loadLibrary method may be used when the directory containing the shared library is in java.library.path. To load «libchilkat.so», call System.loadLibrary(«chilkat»), as shown below.

import com.chilkatsoft.CkZip; public class Test < static < try < System.loadLibrary("chilkat"); > catch (UnsatisfiedLinkError e) < System.err.println("Native code library failed to load.\n" + e); System.exit(1); >> public static void main(String argv[]) < CkZip zip = new CkZip(); System.out.println(zip.version()); >>

3. Modify the LD_LIBRARY_PATH environment variable to include the path where the Chilkat shared library is located.

For Bourne Shell, K Shell or Bash, type:

export LD_LIBRARY_PATH=/home/joe/chilkatJava-9.1.1-x86_64-linux:$LD_LIBRARY_PATH

setenv LD_LIBRARY_PATH "/home/joe/chilkatJava-9.1.1-x86_64-linux:$LD_LIBRARY_PATH"

4. Specify the java.library.path on the command line by using the -D option.

java -Djava.library.path=".:/home/joe/chilkatJava-9.1.1-x86_64-linux" TestApp

Privacy Statement. Copyright 2000-2022 Chilkat Software, Inc. All rights reserved.
(Regarding the usage of the Android logo) Portions of this page are reproduced from work created and shared by Google and used according to terms
described in the Creative Commons 3.0 Attribution License.

Send feedback to info@chilkatsoft.com
Software APIs, modules, components, and libraries for Windows, Linux, MacOS, iOS, Android™, Alpine Linux, Solaris, MinGW, .

Источник

Saved searches

Use saved searches to filter your results more quickly

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.

Native library loader for extracting and loading native libraries from Java.

License

scijava/native-lib-loader

This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.

Name already in use

A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?

Please sign in to use Codespaces.

Launching GitHub Desktop

If nothing happens, download GitHub Desktop and try again.

Launching GitHub Desktop

If nothing happens, download GitHub Desktop and try again.

Launching Xcode

If nothing happens, download Xcode and try again.

Launching Visual Studio Code

Your codespace will open once ready.

There was a problem preparing your codespace, please try again.

Latest commit

Git stats

Files

Failed to load latest commit information.

README.md

About native library loader

The native library loader is a utility that assists with loading native libraries from Java. It provides the ability to painlessly identify, extract and load the correct platform-specific native library from a JAR file.

Search Maven Central for latest version and add a dependency to your pom.xml.

dependency> groupId>org.scijavagroupId> artifactId>native-lib-loaderartifactId> version>x.y.zversion> dependency>

Native libraries should be packaged into a single jar file, with the following directory & file structure:

/natives /linux_32 libxxx[-vvv].so /linux_64 libxxx[-vvv].so /osx_32 libxxx[-vvv].dylib /osx_64 libxxx[-vvv].dylib /osx_arm64 libxxx[-vvv].dylib /windows_32 xxx[-vvv].dll /windows_64 xxx[-vvv].dll /windows_arm64 xxx[-vvv].dll /aix_32 libxxx[-vvv].so libxxx[-vvv].a /aix_64 libxxx[-vvv].so libxxx[-vvv].a

Here «xxx» is the name of the native library and «-vvv» is an optional version number. Depending on the platform at runtime, a native library will be unpacked into a temporary file and will be loaded from there.

The version information will be grabbed from the MANIFEST.mf file from «Implementation-Version» entry. So it’s recommended to follow Java’s package version information convention.

If you want to load ‘awesome.dll’ (on Windows) or ‘libawesome.so’ (on Linux or AIX), simply do like this .

NativeLoader.loadLibrary("awesome");

About

Native library loader for extracting and loading native libraries from Java.

Источник

Saved searches

Use saved searches to filter your results more quickly

A Maven/make framework for loading native C libraries into a Java program

License

uw-dims/java-native-loader

This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.

Name already in use

Please sign in to use Codespaces.

Launching GitHub Desktop

If nothing happens, download GitHub Desktop and try again.

Launching GitHub Desktop

If nothing happens, download GitHub Desktop and try again.

Launching Xcode

If nothing happens, download Xcode and try again.

Launching Visual Studio Code

Your codespace will open once ready.

There was a problem preparing your codespace, please try again.

Latest commit

Git stats

Files

Failed to load latest commit information.

README.md

A Maven-based framework for managing the native (JNI) parts of Java codebases. The idea is to include any .dll/.dylib/.so files in a jar as resources, and to load these via resource loading from the classpath. Generalising the approach taken by [Snappy-Java] (https://github.com/xerial/snappy-java), the compiled library for all available platforms is bundled into a single jar. This gives the illusion of platform independence, pure Java code and thus of a regular Maven build/test/install cycle and seamless dependency management of JNI-contaminated artifacts.

The primary artifact for native library loading is under the main directory:

$ cd java-native-loader/main $ mvn install

A sample Java codebase with JNI parts is at examples/hello-world:

$ cd java-native-loader/examples/hello-world $ mvn test

The following projects use the Java Native Loader framework described here in order to build and then load their own C code:

The [Device Files] (https://github.com/uw-dims/device-files) project enables Java programs to extract low-level disk parameters such as vendor and serial number, plus whole disk size.
The [TSK4J] (https://github.com/uw-dims/tsk4j) project provides an object-oriented view on the [Sleuthkit] (http://www.sleuthkit.org/sleuthkit/) host-forensics library.
The [FUSE4J] (https://github.com/uw-dims/fuse4j) project implements Java bindings to [FUSE] (http://fuse.sourceforge.net).

These are far better examples than the hello-world example above. DeviceFiles needs different C sources and build procedures for different platforms. TSK4J involves linking to third party C libraries. FUSE4J needs both different build procedures (compiler flags differing in 32 vs 64 bit builds) and links to a third party C library.

The examples/hello-world sample shows how to organize the management of JNI resources in this framework:

The [POM] (./examples/hello-world/pom.xml) shows how we use a Maven profile (called native) to drive the C compilation and linking steps. A build without that profile activated results in a regular Java-only Maven build. The POM also uses a set of profiles to ‘canonicalize’ the local architecture string (result of os.arch) to match that assumed by the main [NativeLoader] (./main/src/main/java/edu/uw/apl/nativelibloader/NativeLoader.java) class.
A platform-dependent [Makefile] (examples/hello-world/src/main/native/Linux/x86_64/Makefile) shows how the linked library (in this case an .so file) is transferred to src/main/resources for inclusion in the packaged Maven artifact.
The sample [Hello.java] (examples/hello-world/src/main/java/greetings/Hello.java) shows use of the NativeLoader api located in the main artifact (see above).

The C code for the hello-world sample is simple enough that no platform-specific parts are necessary, so we place all the C code in [src/main/native] (examples/hello-world/src/main/native). More complicated C code may require platform and even bit-ness (32 vs 64) sub-components.

We have compiled the JNI parts of the hello-world sample for Linux only (both 64-bit and 32-bit variants). The .so files end up as resources. Nevertheless, the Maven pom file, Makefiles and directory structure promote a many-platform build (Windows, MacOS, etc). The idea is to create platform and bitness (32/64) specific build scripts (e.g. Makefiles for Linux/Mac OS, .proj/NMAKE files for Windows), and build C sources from those. The resulting .so/.dylib/.dll files, once transferred to src/main/resources, are then put under version control, so need building only once per platform. We treat the .so/.dylib/.dll products essentially as source code components, with a Maven profile-driven build of those platform-specific parts. The net effect is that the C parts of a split Java/C build become almost as easy to manage as regular Java classes.

Источник

Java load native library linux