SymbolLookup.loaderLookup() vs SymbolLookup.libraryLookup()

[Manuel Bleichenbacher]

If code is created for libudev (on Linux) with the  command:

    jextract --source -l udev --include-function udev_new
/usr/include/libudev.h

the resulting code fails at run-time with:

java.lang.UnsatisfiedLinkError: no udev in java.library.path:
/usr/java/packages/lib:/usr/lib64:/lib64:/lib:/usr/lib

That's of course correct as the libudev is in /usr/lib/x86_64-linux-gnu.
But it isn't just a random application specific directory. It's a directory
that is searched for libraries by default (depending on the architecture
the name changes) and contains many basic libraries for Linux.

The generated code can be fixed easily with a minor modification. Instead
of the generated code (in RuntimeHelper.java):

        System.loadLibrary("udev");
        SymbolLookup loaderLookup = SymbolLookup.loaderLookup();

one can just put:

        SymbolLookup loaderLookup =
SymbolLookup.libraryLookup("libudev.so", MemorySession.openImplicit());

Would it be possible to add an option to jextract so it generates code
using SymbolLookup.libraryLookup() instead of SymbolLookup.loaderLookup()
and does not generate a call to System.loadLibrary()?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jextract-dev/attachments/20220830/c6a8a5ad/attachment.htm>