OS/X OpenGL

[Michael Hall]

> On May 10, 2023, at 3:40 AM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
> 
> 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.

On OS/X this would be dylib instead of .so. Possibly I was forgetting the automatic lib prefix, I’ll have to check. For searching I thought also indicating the location with -Djava.library.path would resolve it.

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

My assumption that missing dlopen was why the DYLD_ env variables don’t seem to be working is then incorrect. But so far they don’t seem to be doing anything.

> 
> * 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").

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

Thanks.

Mike