OS/X OpenGL

Wed May 10 12:13:28 UTC 2023

> 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?
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.

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.

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:

> When _path_ doesn't contain a slash character (i.e. it is just a leaf 
> name), *dlopen*() 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 _path_ 
> contains a slash (i.e. a full path or a partial path) *dlopen*() 
> searches the following the following until it finds a compatible 
> Mach-O file: $DYLD_LIBRARY_PATH (with leaf name from _path_ ), current 
> working directory (for partial paths), $DYLD_FALLBACK_LIBRARY_PATH 
> (with leaf name from _path_ ).

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]:

> 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 |dlopen()| the path, which 
> will correctly check for the library in the cache. (62986286)

(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).

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?)

[1] - 
https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man3/dlopen.3.html
[2] - 
https://developer.apple.com/documentation/macos-release-notes/macos-big-sur-11_0_1-release-notes

Maurizio

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20230510/dd993d90/attachment.htm>