library loading - continued
notzed at gmail.com
Tue May 11 02:06:45 UTC 2021
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
More information about the panama-dev