[foreign] RFC: Jextract -l options ignored by SymbolFilter when -L is not specified

[Henry Jen]

> On Jan 23, 2019, at 6:19 AM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
> 
> One extra element to your good summary - it is true that with ld, if a library is not found, its a fatal error.
> 
> But, if we decided to go ahead and implement the library-centric approach we've been talking about, I think jextract should always be able to find the library at extraction time, to be able to compute the root symbols accordingly.
> 
> I think this means that the answer to the first bullet in your summary should be no (at least with the library-centric approach it doesn't make sense not to have a library available at extraction time, I think).
> 

This is what I am expecting. However, we can decide whether to tolerate missing library with a warning and run as if the -l not specified except to record the library name and generating the static forwarding class.

Cheers,
Henry

> Maurizio
> 
> On 23/01/2019 13:11, Sundararajan Athijegannathan wrote:
>> * Not finding a library in default library search path is fatal for "ld". For jextract, it is just that additional functionality would be missed. We just record library name and leave the configuration to binder. So -L is not mandatory for jextract. Symbol missing is left for the binder to find & report. If we allow even late resolution in binder (per native method instead of per interface), it'd be like JNI. I'm not sure we should fix it by jextract throwing error when not finding a library.
>> 
>> * When -L is specified, jextract warns missing symbols and does not generate corresponding function in interface. "ld" would throw error for missing symbols and won't link.
>> 
>> * Finally jextract uses -L value for runtime search path as well if --infer-path is turned on.
>> 
>> Yes, all divergences are our creation. Initially started with similarities but over the time kept adding features. Hence I thought we should perhaps use a different name and be uniform with --module-path, --class-path. That said, I'm not too religious about it :)
>> 
>> Summary:
>> 
>> * Should it be okay to skip jextract time ("tool time") checks completely and just record library name in annotation? (consistent with Java's late binding).
>> 
>> * We need a way to specify library path for search (a) for jextract time checks. (b) to help binder for runtime search of the libraries
>> 
>> * Should there be a default for library path? If so, how to infer it?  java.library.path or other System property, env. var. (old/new) ?
>> - java.library.path is not stable across platforms and may not be useful. Should we use the same default as used by the platform "ld"?
>> 
>> * We need a way to tell what to do on missing symbols? (none/warn/error/warn-and-skip-method)
>> 
>> -Sundar
>> 
>> On 23/01/19, 4:40 PM, Maurizio Cimadamore wrote:
>>> 
>>> On 23/01/2019 10:49, Jorn Vernee wrote:
>>>> That jextract's -L also has the added functionality of turning on symbol checking.
>>> 
>>> So... if we follow the 'should be like the C toolchain' metaphore, this doesn't make a lot of sense.
>>> 
>>> With clang or gcc, I can specify loads of paths (or none) in -L and that's fine. The linker trigger is "-l", not "-L".
>>> 
>>> In other words, I think the 'divergence' we are talking about here, is pretty much our own creation.
>>> 
>>> What happens when you say, e.g.
>>> 
>>> gcc -l GL
>>> 
>>> the linker will try its best to locate the GL library - if it cannot find it, error.
>>> 
>>> How do you solve the error? With -L
>>> 
>>> gcc -l GL -L foo/bar
>>> 
>>> So, there is a possible universe in which jextract "-l" triggers symbol checks (which we can define as the equivalent of the linker job at extraction time). If jextract cannot find a shared library, it will fail badly. Then the user will have to specify -L to tell jextract where to find the desired library.
>>> 
>>> This seems pretty much on par with what we have on the C toolchain side.
>>> 
>>> The problem right now is that, as you say, the absence of -L turns off the symbol checking. That is, jextract won't even try (and won't give any error). This is the bit that is not compatible with the C toolchain, IMHO, and is something that can be rectified.
>>> 
>>> Then there's an orthogonal question as to what should the default -L search path be if none is specified - and I can see different answers there (none, current dir, java.library.path) - but that is an orthogonal issue.
>>> 
>>> Maurizio
>>> 
>>>> 
>>>> Jorn
>>>> 
>>>> Maurizio Cimadamore schreef op 2019-01-23 11:41:
>>>>> On 23/01/2019 10:05, Jorn Vernee wrote:
>>>>> 
>>>>>>> Because -L seems to suggest that the option is same/similar to
>>>>>>> platform linker option. That is why we started. But now that we
>>>>>>> are
>>>>>>> deviating, a different name is better. Besides --library-path
>>>>>>> makes it
>>>>>>> more like --module-path, --class-path of the Java world.
>>>>>> 
>>>>>> Ok, I see. That makes sense, especially when combined with the
>>>>>> `--missing-symbols=warn|error|exclude` option you mentioned as well.
>>>>> 
>>>>> I'm not sure I understand this point - what is the deviation we're
>>>>> talking about?
>>>>> 
>>>>> Maurizio