<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p>Hi Chris,<br>
Pedro is correct -- library loading is based on what capability is
provided by the OS (typically, some form of `dlopen`). In most OS,
the argument to dlopen (or equivalent) must be a file descriptor.
This is why existing workarounds need to dump the packaged native
libraries in /tmp, so that the OS would be able to load them.</p>
<p>I agree this practice is brittle, and in some cases (as you point
out) access to /tmp is not even available. If you live in a
modular world and you can build your own JDK image (with jlink),
then there's an elegant solution to this: create a jmod for the
Java library. The jmod file can also contain native libraries that
will, once linked in a modular image, be placed inside the "lib"
folder of the image, so that they will be discoverable at runtime.
This is the way in which, for instance, we package jextract.</p>
<p>But this is, sadly, not the world the majority of the world lives
in. Build tools like Maven and Gradle don't understand jlink
images and jmod files (nor do IDEs). I do hope that the status quo
will change, and that adoption of custom images, especially in the
case of projects with native library becomes more popular (but to
do so, popular tools and framework would need to lead the way).</p>
<p>Failing that, our best bet is that better library loading
facilities become more widely available (like fdlopen). I know
linux has something called memfd_create [1], which allows to
create a file descriptor from shared memory. I have not tried to
see if it can be used to load libraries directly from memory, but
we'd be curious to know if anybody did, and what kind of
limitations would derive from doing things that way.</p>
<p>Cheers<br>
Maurizio<br>
<br>
[1] - <a class="moz-txt-link-freetext" href="https://man7.org/linux/man-pages/man2/memfd_create.2.html">https://man7.org/linux/man-pages/man2/memfd_create.2.html</a><br>
</p>
<br>
<div class="moz-cite-prefix">On 16/01/2025 18:54, Pedro Lamarão
wrote:<br>
</div>
<blockquote type="cite" cite="mid:CAC8PkgFncDxDFTn6aEhbgPOYrjRa5s8fEK-omSdYBuS7FkAbiQ@mail.gmail.com">
<div dir="ltr">
<div dir="ltr">Hi Chris!
<div>as a way forward, see for example FreeBSD's fdlopen:</div>
<div><a href="https://man.freebsd.org/cgi/man.cgi?fdlopen(3)" moz-do-not-send="true" class="moz-txt-link-freetext">https://man.freebsd.org/cgi/man.cgi?fdlopen(3)</a></div>
<div>Generally, we need the dynamic loader to allow loading
from alternative storage.</div>
<div>Atte.</div>
<div>Pedro.</div>
<div><br>
</div>
<div><br>
</div>
</div>
<br>
<div class="gmail_quote gmail_quote_container">
<div dir="ltr" class="gmail_attr">Em qui., 16 de jan. de 2025
às 15:48, Chris Vest <<a href="mailto:mr.chrisvest@gmail.com" moz-do-not-send="true" class="moz-txt-link-freetext">mr.chrisvest@gmail.com</a>>
escreveu:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">Hi,
<div><br>
</div>
<div>SymbolLookup and the older System.load/loadLibrary
all make the assumption that any library we wish to load
is located in a file on the, er, "native" file system.</div>
<div><br>
</div>
<div>I guess this is a limitation inherited from dlopen
and LoadLibrary.</div>
<div><br>
</div>
<div>Many Java projects that include native code, then
tend to package their native libraries as part of their
jar files, and extract them to /tmp, or the like, before
loading them.</div>
<div><br>
</div>
<div>This old practice is starting to become problematic,
since /tmp is now often mounted with noexec for
security.</div>
<div><br>
</div>
<div>So, is there some possible path forward that'll allow
us to load libraries from e.g. a memory segment instead
of a file?</div>
<div><br>
</div>
<div>Thanks,</div>
<div>Chris</div>
</div>
</blockquote>
</div>
<div><br>
</div>
</div>
</blockquote>
</body>
</html>