Project Panama & dynamic library loading

[Ty Young]

On 9/7/19 12:14 PM, Maurizio Cimadamore wrote:
>
> On 07/09/2019 05:17, Ty Young wrote:
>>
>> On 9/6/19 11:04 PM, Henry Jen wrote:
>>>
>>>> On Sep 6, 2019, at 6:47 PM, Ty Young <youngty1997 at gmail.com> wrote:
>>>>
>>>>
>>>> On 9/6/19 8:12 PM, Henry Jen wrote:
>>>>>> On Sep 6, 2019, at 4:58 PM, Ty Young <youngty1997 at gmail.com> wrote:
>>>>>>
>>>>>>
>>>>>> On 9/6/19 6:36 PM, Ty Young wrote:
>>>>>>> On Fri, Sep 6, 2019 at 6:34 PM, Maurizio Cimadamore 
>>>>>>> <maurizio.cimadamore at oracle.com> wrote:
>>>>>>>> Hi Ty, you are not forced to save the library path in the 
>>>>>>>> generated extracted jar with the --record-library-path  option. 
>>>>>>>> If you can also omit that option, and then set 
>>>>>>>> java.library.path (or LD_LIBRARY_PATH) accordingly when it's 
>>>>>>>> time to run your application.
>>>>>> Can java.library.path be modified in code or does it have to be a 
>>>>>> launch option to work? I've always assumed it was a launch option 
>>>>>> only and haven't thought much of it.
>>>>>>
>>>>> It’s a launch option, and thus can adapt to your deployment 
>>>>> environment.
>>>>
>>>> There is no specific "deployment environment". If you were to 
>>>> create bindings in Arch Linux you'd need to specify the pathing for 
>>>> every other Linux distro and even Windows, resulting in not working 
>>>> on more obscure Linux distros and two different builds between 
>>>> Windows and Linux. If you could just dynamically add the paths 
>>>> that'd make this so much easier…
>>>>
>>> In this case, you are looking for a sane system default, which as 
>>> Mauricio mentioned, we need to look for better ways. OpenJDK by 
>>> default is not providing proper value across various Linux distros. 
>>> But java.library.path provide a way to accommodate that. Also, it’s 
>>> possible to
>>>
>>> Usually, a Linux distro will have a customized OpenJDK package has 
>>> customized default.
>>>
>>>>>> It would really be nice if the whole thing was dynamic with zero 
>>>>>> hardcoded values, even if startup time was sacrificed due to 
>>>>>> library searching. With how fragmented the Linux ecosystem 
>>>>>> specifically is, there is never any guarantee that any hardcoded 
>>>>>> values(s) will work for all Linux distros.
>>>>>>
>>>>> Dynamic loading is supported since beginning, typical code snippet 
>>>>> is like following.
>>>>>
>>>>> Library lib = Libraries.loadLibrary(MethodHandles.lookup(), 
>>>>> "tensorflow");
>>>>> libTF = Libraries.bind(c_api_h.class, lib);
>>>>>
>>>>> As long as you define java.library.path to include correct search 
>>>>> path for the native library, it should work just fine.
>>>>
>>>> The search path being static is the problem here. Without a dynamic 
>>>> way to add libraries easily things will blowup real badly.
>>>>
>>>>
>>> With jextract, combine -L option with -l and —record-library-path, 
>>> the provided search paths is saved to be used for runtime. I know 
>>> it’s not the same as an API, but provide the behavior you described?
>>
>>
>> Path(s) or path? None of the examples that I see show multiple 
>> library paths being specified. If it is possible then sure, I guess. 
>> It's still hardcoded and could break but at least I'll have the three 
>> major distros covered and don't have to copy libraries around...
>>
>>
>> That said, can a Windows path be specified alongside the Linux paths?
>
> When you use --record-library-path whatever path you specify with -L 
> will end up saved in the generated annotations. You can put 
> non-existent paths in there - it's no harm, they will be just ignored 
> at runtime on th eplatforms where they don't make sense.


Alright, but how do you specify multiple paths? Something like this:


-L /usr/lib:/usr/lib64


Or does it have its own unique regex?


>
> Maurizio
>
>>
>>
>>>
>>> Cheers,
>>> Henry
>>>