Project Panama & dynamic library loading

[Maurizio Cimadamore]

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.

Maurizio

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