Linking to macOS frameworks

[Clayton Walker]

I've since updated to the most recent panama build, panama+3-167.

Under Mojave I can load the IOKit library via
System.load("/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit");
and then lookup the symbol "IORegistryGetRootEntry" via loaderLookup,
however under Big Sur this code no longer works. While I can call
dlopen manually under Big Sur, that doesn't make the symbols in the
loaded library available to loaderLookup. This makes it frustrating
trying to bind to native libraries on macOS.
 I guess a workaround might be to create a dylib that links to a
framework, then load that? But then you're back shipping native
library shims.

At least during testing, removing the file.exists() check from
NativeLibaries.loadLibrary allowed the code to properly work under Big
Sur.

On Wed, May 19, 2021 at 3:12 PM Maurizio Cimadamore
<maurizio.cimadamore at oracle.com> wrote:
>
> I see.
>
> Obviously some kind of workaround is happening behind the scene when
> dlopen is invoked with that library name, as a compatibility measure.
>
> If you load this:
>
> /usr/lib/libSystem.B.dylib
>
> Do you, by any change, get access to the symbols you want?
>
> Anyway - to your original question, LibraryLookup.ofPath works with a
> library file in the file system. Here it seems a case where libraries
> are not in the file system, but in some other cache, and dlopen has been
> instructed to "work" when asked with certain well-known names.
>
> In this case, if the above trick (libSystem) doesn't work, the only
> thing left to you might well be calling dlopen directly.
>
> Maurizio
>
> On 19/05/2021 20:31, Clayton Walker wrote:
> > Hi Maurizio,
> >
> > Yes, UserNotification is a library, but unfortunately
> > UserNotification.dylib is no longer in that folder.
> > Per this page https://urldefense.com/v3/__https://developer.apple.com/documentation/macos-release-notes/macos-big-sur-11_0_1-release-notes__;!!GqivPVa7Brio!PxJkXokERrp3NAcaRqK7q1eIHPqhs9AWyxmbu4_AfBKvGVbf2OcqtR2HUvwImxChbwHDpmE$ ,
> > Apple's release notes state
> > `copies of dynamic libraries are no longer present on the filesystem`.
> > So while previously they did exist on the filesystem, now they're not.
> > dlopen still handles the path on macOS Big Sur,
> > dlopen("/System/Library/Frameworks/UserNotifications.framework/Versions/Current/UserNotifications");
> > works.
> >
> >
> > On Wed, May 19, 2021 at 11:03 AM Maurizio Cimadamore
> > <maurizio.cimadamore at oracle.com> wrote:
> >> Hi Clayton,
> >> Is UserNotification a library? E.g. is there a file
> >> UserNotification.dylib in that folder?
> >>
> >> If so, just use "Library.ofPath" and include the suffix - as that method
> >> wants the library absolute path.
> >>
> >> Maurizio
> >>
> >> On 19/05/2021 17:46, Clayton Walker wrote:
> >>> Hello,
> >>>
> >>> I'm working on a project that would let you call objective-c functions from
> >>> java, without first needing to wrap the api in a shared library. While this
> >>> works for symbols that are already available
> >>> (i.e.LibraryLookup.ofDefault().lookup("objc_getClass")), it doesn't work
> >>> for symbols that are in another framework.
> >>>
> >>> For example, I would like to be able to write something like this:
> >>> LibraryLookup.ofLibrary("/System/Library/Frameworks/UserNotifications.framework/Versions/Current/UserNotifications");
> >>> // or
> >>> LibraryLookup.ofPath(Path.of("/System/Library/Frameworks/UserNotifications.framework/Versions/Current/UserNotifications"));
> >>> however this currently doesn't work. The first call throws with "Directory
> >>> separator should not appear in library name", second one throws with
> >>> "Library not found".
> >>>
> >>> I've been able to work around this by using dlopen
> >>> MemoryAddress l1;
> >>> try (var c =
> >>> CLinker.toCString("/System/Library/Frameworks/UserNotifications.framework/Versions/Current/UserNotifications"))
> >>> {
> >>>       l1 = (MemoryAddress) dlopen.invokeExact(c.address(), 1);
> >>> }
> >>> but this seems rather strange. It looks like LibraryLookup.ofPath requires
> >>> the path to exist, whereas in Big Sur the files no longer exist (via
> >>> https://urldefense.com/v3/__https://developer.apple.com/forums/thread/657267__;!!GqivPVa7Brio!PxJkXokERrp3NAcaRqK7q1eIHPqhs9AWyxmbu4_AfBKvGVbf2OcqtR2HUvwImxChS2opDZY$ ).