How to tell jextract to use different lib name for the same binding?

[Maurizio Cimadamore]

That is an option, yes. But it hinges on the ability to find the library 
using the _loader_ lookup (SymbolLookup::loaderLookup) -- which relies 
on java.library.path.

SInce Davide is working on Linux, I'm assuming he was kind of relying on 
the ability of the _library_ lookup (SymbolLookup::libraryLookup) to 
find libraries in system paths (because library lookup can see all the 
library names known to the dynamic linker, w/o the need to specify 
java.library.path). But if that's not the case, then yes, specifying no 
library (and maybe do some System::loadLibrary in a static initializer 
of the appllication) might be a good idea/workaround.

Thanks
Maurizio

On 13/11/2024 11:02, Christoph Läubrich wrote:
> What I did in the past is to simply not specify the library to 
> jextract at all.
>
> The one of course need to load that in the application code, but at 
> this place you can do whatever you want (including trying different 
> names).
>
> Maybe this works here as well?
>
> Am 13.11.24 um 11:50 schrieb Maurizio Cimadamore:
>> Hi,
>> thanks for the feedback, and the positive comments :-)
>>
>> I see what you mean - you basically have two possible names for the 
>> library, and either one or the other should "match".
>>
>> Now, the jextract code could be updated a little. For instance, 
>> jextract could be a bit smarter when creating the library lookup: if 
>> an exception is thrown, some kind of "empty lookup" could be used. 
>> This would avoid exceptions being thrown.
>>
>> This is doable -- but the question then becomes: what if a user 
>> really expects a library to be there? In that case, the exception 
>> would be "swallowed" only to pop up later, e.g. when the first 
>> downcall is created (at which point the bindings will fail because no 
>> symbol for the downcall could be found -- given the library has not 
>> been loaded at all).
>>
>> So, doing a change like the one you suggest amounts at attempting to 
>> read the user mind (and all tools -- jextract included -- are 
>> notoriously bad at that :-) ). Now, it might be that the "exception 
>> swallowing" behavior I described above is more generally useful than 
>> what we do now, but with things like these I'm always afraid that 
>> what's best for some developers might not be best for others. So... 
>> we need more feedback from all of you to understand whether such a 
>> change would be perceived as beneficial.
>>
>> A similar issue was also discussed here:
>>
>> https://mail.openjdk.org/pipermail/jextract-dev/2024-September/001949.html 
>>
>>
>> Note also that, longer term (as mentioned in that discussion) we have 
>> plans to allow custom SymbolLookups to be plugged in by users, so 
>> that jextract can get away with "less mind reading".
>>
>> Cheers
>> Maurizio
>>
>> On 13/11/2024 10:35, Davide Perini wrote:
>>>
>>> Hi all,
>>> I'm starting to use jextract to workaround some issues I found in AWT.
>>> AWT uses 20+ years old APIs for notifications and tray icons and it 
>>> doesn't work well in recent Linux distros and on Windows 11 24H2.
>>>
>>> I must say that foreign memory API is a massive improvement to the 
>>> Java ecosystem, wow.
>>> I created a binding for the tray icon and for the notification API 
>>> in minutes, this is awesome.
>>>
>>> To create my bindings I start with jextract with something like this:
>>> jextract \
>>> -l ayatana-appindicator3 \
>>> -l appindicator3 \
>>> ....
>>> /usr/include/libayatana-appindicator3-0.1/libayatana-appindicator/app-indicator.h 
>>>
>>>
>>>
>>> With this command I would tell to jextract to search for
>>> ayatana-appindicator3
>>> or
>>> appindicator3
>>>
>>> but when I use the binding it throws an exception if one of the two 
>>> libs are not present.
>>>
>>>
>>> Libs uses the same interfaces and I don't need two bindings for 
>>> these two libraries.
>>>
>>> Is it possible to tell to jextract to create a binding that searches 
>>> for "multiple lib name" and don't throw and error in the event that 
>>> one lib is found?
>>>
>>> Thanks
>>> Davide
>>>