OS/X OpenGL

[Maurizio Cimadamore]

Hi Michael. A couple of notes here:

* System.load/loadLibrary have some special rules in how the library 
lookup is performed. For instance, loadLibrary adds "lib" and appends 
".so" on the library name on Linux, and only looks in some specific 
folders (e.g. /usr/lib) which is typically not enough in modern systems.

* SymbolLookup.libraryLookup(String) is just a wrapper around dlopen. 
What you need to pass is the library name that would be resolved by the 
dynamic linker. E.g. "libc.so.6". In other words, this is very useful to 
load libraries that should be installed on your system (and will load 
the right version, by just delegating to the dynamic linker).

* SymbolLookup.libraryLookup(Path) is an escape hatch which loads a 
library in a given path. In that way, it's similar to System.load, but 
with the extra benefit that you can unload the library when done.

So, if what you want to load is the "official" libGL, libglut installed 
on your system (e.g. via apt or other means), you should use the 
libraryLookup(String) variant, e.g. libraryLookup("libGL.so"). On linux, 
you can verify if that's a valid name by running "ldconfig -p", which 
will list all library names known in your system.

Given all this, I think providing a list of paths to libraryLookup(Path) 
feels a bit odd: the path you pass in there is assumed to point to a 
full, valid, library absolute path. There's no search involved. So you 
either look by dlopen name (and delegate the search to dlopen) or you 
provide the full path explicitly (e.g. "I know I want to use the library 
over there").

What you suggest in the comment, however, is a good idea (and one we 
have considered): e.g. add an "andThen" method which allows to chain 
together multiple SymbolLookups. This is something that is totally 
doable, especially given a lookup returns an optional, so these things 
do compose.

Hope this helps.

Cheers
Maurizio

On 10/05/2023 09:02, Michael Hall wrote:
> Still looking at this a little bit from time to time.
>
> On my prior I noted java invocation including something like…
>
> DYLD_PRINT_LIBRARIES=1 DYLD_PRINT_APIS=1
>
> These do not appear to work. In looking I am currently assuming this is due to dlopen is not used. Is this correct?
>
> I saw that it appears JNI loading can be used...
>
> System.load("/opt/X11/lib/libglut.dylib”);
>
> That I assume would restore the above to working? However, load doesn’t appear to do so that I’ve noticed and loadLibrary for some reason isn’t working for the libraries of interest getting link errors.
>
> With load it appears I need to use…
>
> SymbolLookup loaderLookup = SymbolLookup.loaderLookup();
>
> To access things via the class loader.
>
> OS/X seems to have removed some of its OpenGL support from frameworks. So I am trying to build something to use from Mesa. Quartz X11 also still seems to provide some of this.
> Being unsure I was in fact getting the correct version of the libraries and with loadLibrary not working I went to this running on the main thread…
>
> 	private static final Arena MAIN_ARENA = Arena.openConfined();
>          SymbolLookup libraryLookup = SymbolLookup.libraryLookup("/Users/mjh/Documents/java/panama/mesa-23.0.1/os/lib/libGL.dylib", MAIN_ARENA.scope());
>
> With this to manage the symbol lookup…
>
>          SYMBOL_LOOKUP = name -> libraryLookup.find(name); // .or(() -> loaderLookup.find(name));    // .or(() -> LINKER.defaultLookup().find(name));
>
> This errored because I am currently omitting the class loader lookup needed for the libglut.dylib above. I also failed to chain all three lookups probably because I’m not that familiar with the lambda syntax.
>
> It did occur to me that I could simplify somewhat if I combined the libGL and and libglut. So the actual question/suggestion is would it make sense to have libraryLookup allow a list of paths to be provided?
> Like the java.class.path or java.library.path system properties do?
>
>