library loading - continued

[Michael Zucchi]

On 11/5/21 10:38 am, Ty Young wrote:
> Someone off-list pointed out that dl* functions are provided by a 
> different library than libc: dl. 

Oops, hit the wrong button.  As below:


On 11/5/21 7:55 am, Ty Young wrote:
> It's not possible to create bindings for dlfcn, the header that 
> provides the function declarations dlopen, dlclose, dlsym, etc, it 
> seems. CLinker.systemLookup() fails to provide the symbol, anyway, and 
> attempting to load libc fails. The header says that it's part of the 
> GNU C library but maybe I'm barking up the wrong tree or something.
>

For glibc they're in libdl not libc (as per man page), is that the problem?

>
> Is System.load()/System.loadLibrary() really the best approach? Not 
> only does it have issues loading libc(and others?) but it isn't 
> exactly all that primitive of a API either. Both dlopen(Linux) and 
> LoadLibrary(Windows) both return pointers(which can be user managed) 
> when loading libraries and dlopen has modes that can be set, but 
> System.load()/System.loadLibrary() both register the loaded libraries 
> with a ClassLoader, a JVM construct. How does one get a pointer of a 
> loaded library from a ClassLoader and then use that pointer to unload 
> a library?
>
>
It does seem overly complicated when all the supported operating systems 
have a pretty basic and very similar abstraction.

On that last point should one ever explicitly unload a library though?  
Presumably tying it to a (specific) classloader does the same thing in a 
"safe" way.

  Z