search

Pi4J / pi4j-v1

DEPRECATED Java I/O library for Raspberry Pi (GPIO, I2C, SPI, UART)
http://www.pi4j.com
Apache License 2.0
1.31k stars 447 forks source link

Fails to work on systems that have noexec /tmp #454

Closed maxnet closed 3 years ago

maxnet commented 5 years ago

It would be nice if libpi4j.so was just a plain normal file in the file system, instead of your current logic of embedding it in the .jar and extracting it to /tmp at runtime. Fails to work on systems that have /tmp mounted noexec...

savageautomate commented 4 years ago

related issue: https://github.com/Pi4J/pi4j/issues/491

FDelporte commented 4 years ago

@maxnet see https://v2.pi4j.com/library-path for a possible work-around

maxnet commented 4 years ago

@maxnet see https://v2.pi4j.com/library-path for a possible work-around

I am afraid such workarounds are too difficult for the target audience. Not reported the issue for myself, but because a school teacher complained that Pi4j did not work with Piserver (PXE network boot software to manage class rooms).

savageautomate commented 4 years ago

We could probably detect non-write access to /tmp and then attempt to resolve the native library in the system library path. Pi4J does not install the native library via the dpkg installer, but this .SO file could be placed by the user. Do you think this would work?

I realize this is an old issue but we are also attempting to resolve issues like this for the new Pi4J V2 project in advance of a release.

Thanks, Robert

maxnet commented 4 years ago

We could probably detect non-write access to /tmp and then attempt to resolve the native library in the system library path. Pi4J does not install the native library via the dpkg installer, but this .SO file could be placed by the user.

Still sounds more difficult than it should be.

What is the reason the .so is not installed by you in /opt/pi4j/lib as normal file? There is no rule requiring it to be in the system library path, right? (you are able to use it in /tmp after all...)

savageautomate commented 4 years ago

What is the reason the .so is not installed by you in /opt/pi4j/lib as normal file?

Well .... originally Pi4J was not distributed via a package installer (*.deb) as well a many users could obtain the Pi4J JARs via dependency management tools like Gradle and Maven. Additionally many beginners and novice Java programmers did not really understand native libraries and how the JNI system works. So for portability reasons and an effort to simplify the adoption for most users we embedded the native library (libpi4j.so) inside the JAR's resources and extract it at runtime to load it into the JVM. This also made the dependency versioning and API compatibility between the JNI Java library and the native .SO always in sync.

So right or wrong, this was the approach that was adopted. However, clearly there are a few consequences noexec /tmp being just one of them.

There is no rule requiring it to be in the system library path, right? (you are able to use it in /tmp after all...)

No, no rule. We can load it from any fixed path. The runtime just needs to know what path to use.

savageautomate commented 3 years ago

Closing with workaround in Pi4J v1.3.

Added support for system property ("pi4j.library.path") to override default embedded library resolution and allow for user explicitly defined resolution path for libpi4j.so native library.

If there is no /tmp available, then the Pi4J JAR does not have a location to extract the embedded ("libpi4j.so") native library. The library will need to be extracted and place on the system and a path provided using this system property. Note: you can also use "system" or "local" to have the JAR look for the "libpi4j.so" native library in the system path or in the local runtime directory alongside the JAR file.