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

[Sundararajan Athijegannathan]

* 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