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

[Maurizio Cimadamore]

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