<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p><br>
</p>
<br>
<blockquote type="cite" cite="mid:BA2D472C-BBC8-4DEF-9BA3-F03AAB95A19E@gmail.com">
<pre class="moz-quote-pre" wrap="">
I’m not quite sure I’m understanding the difference between the libraryLookup String and the default lookup. I can see if OS/X supports the ldconfig command, I’m not familiar with it. In my case I used JNI load for the X11 glut library while deciding to try later to use libraryLookup for libGL. I do need both it appears. So for me at least 2 libraries need to be searched? Chaining could maybe resolve this. But if the situation was even more complex. With maybe 5 libraries involved, is chaining going to get awkward?
I looked a little at the nio api’s and didn’t see where they support path lists either. So maybe it isn’t a really natural approach. But there are cases in System properties where it is done. It almost seems like libraryLookup(Path) is like java.library.path? </pre>
</blockquote>
Linker.defaultLookup returns a lookup which might contain "common"
symbols - e.g. symbols defined in the standard C library. The
contents of a default lookup are not specified and you should not
rely too much on it (unless you want to call stuff like "qsort",
"strlen" etc.). No library loading happens here.
<p>SymbolLookup::libraryLookup takes either a OS-specific library
name (e.g. "libGL.dlsym"), or an absolute path (e.g.
"/usr/lib/libGL.dlsym") and pass that thing to dlopen. If the
library does exist, it is loaded, and its lifetime tied to that of
the provided Arena/Scope. How the library is looked up if the
argument to dlopen is **not** an absolute path is OS-specific.</p>
<p>For instance, looking at the man page for dlopen in MacOSX, it
seems like there's no "cache" for library names like on Linux.
But, the man page says the following:</p>
<p> </p>
<blockquote type="cite">
<pre class="manpages"><tt>When <u>path</u> doesn't contain a slash character (i.e. it is just a leaf
name), <b>dlopen</b>() searches the following the following until it finds a
compatible Mach-O file: $LD_LIBRARY_PATH, $DYLD_LIBRARY_PATH, current
working directory, $DYLD_FALLBACK_LIBRARY_PATH.
When <u>path</u> contains a slash (i.e. a full path or a partial path) <b>dlopen</b>()
searches the following the following until it finds a compatible Mach-O
file: $DYLD_LIBRARY_PATH (with leaf name from <u>path</u> ), current working
directory (for partial paths), $DYLD_FALLBACK_LIBRARY_PATH (with leaf
name from <u>path</u> ).</tt></pre>
</blockquote>
<p>
This seems to suggest that setting either LD_LIBRARY_PATH or
DYLD_LIBRARY_PATH and then pass a library name _without slashes_
should work. Alternatively, you can use a full absolute path.
There is no "java.library.path" equivalent for SymbolLookup, and
for good reasons: the main point of using
SymbolLookup::libraryLookup is to get "closer" to what the OS
library loading actually does and bypass all the "sanitization"
that JNI-oriented methods like System.loadLibrary typically apply
to the incoming argument. Case in point: MacOS has changed the way
in which system shared libraries are distributed - they no longer
have a "path" equivalent in the OS [2]:</p>
<p>
<blockquote type="cite">New in macOS Big Sur 11.0.1, the system
ships with a built-in dynamic linker cache of all
system-provided libraries. As part of this change, copies of
dynamic libraries are no longer present on the filesystem. Code
that attempts to check for dynamic library presence by looking
for a file at a path or enumerating a directory will fail.
Instead, check for library presence by attempting to <code data-v-88c637be="">dlopen()</code> the path, which will
correctly check for the library in the cache. (62986286)</blockquote>
</p>
<p>(Another case is, on Linux, the fact that dlopen can use names in
the linker cache, which is a behavior not available when using
System::loadLibrary).<br>
<br>
</p>
<p>Regarding your last point on chaining, I'm not sure what you mean
by "more complex situation": if you have 5 libraries, you need a
composite lookup that has 5 leaf lookups - I doesn't seem to
change things much? (and, actually, I think keeping a 1-1
correspondence between leaf lookups and library helps?)<br>
</p>
<p>[1] -
<a class="moz-txt-link-freetext" href="https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man3/dlopen.3.html">https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man3/dlopen.3.html</a><br>
[2] -
<a class="moz-txt-link-freetext" href="https://developer.apple.com/documentation/macos-release-notes/macos-big-sur-11_0_1-release-notes">https://developer.apple.com/documentation/macos-release-notes/macos-big-sur-11_0_1-release-notes</a><br>
</p>
<p>Maurizio<br>
</p>
<p><br>
</p>
<p><br>
</p>
<p><br>
</p>
</body>
</html>