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

[Maurizio Cimadamore]

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).

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