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

[Henry Jen]

> On Jan 22, 2019, at 3:55 AM, Jorn Vernee <jbvernee at xs4all.nl> wrote:
> 
> I see, that paints a clear picture thanks. So as far as libraries go:
> 
> "-l" : record library name in @NativeHeader::libraries
> "-rpath" : record runtime library path in @NativeHeader::libraryPaths
> "-L" : do symbol checking using the libraries specified by "-l"
> "--infer-rpath" : infer "-rpath" values from "-L" values
> 
> The picture I had was:
> 
> "-l" : record library name in @NativeHeader::libraries AND do symbol checking with this library
> "-rpath" : record runtime library path in @NativeHeader::libraryPaths
> "-L" : provide lookup paths to load libraries for "-l"
> "--infer-rpath" : infer "-rpath" values from "-L” values
> 

I am actually with Jorn on this.

Cheers,
Henry

> The current "-L" semantics seem a little unintuitive to me to be honest, since "-L" also provide the lookup paths for "-l”.

> 

> If depending on java.library.path to load libraries with "-l" is intended, I would propose replacing the "-L" option with something like a "--filter-symbols" option, and have users use java.library.path to provide the paths used to load the libraries for "-l", and then have "--infer-rpath" copy the paths from java.library.path instead. That way we have only one source of library paths (java.library.path).
> 
> What do you think?
> 
> Jorn
> 
> Sundararajan Athijegannathan schreef op 2019-01-22 06:41:
>> I don't think it is a bug - afaik it is as per design. The primary use
>> of "-l" is to record the library in annotation of the generated jar -
>> so that binder can auto-load the library (either from
>> java.library.path configuration or -rpath value recorded in
>> annotation).  It is okay to record name of the shared object alone and
>> leave the library path configuration to java.library.path setting.
>> "-L" option is added feature to perform missing symbols checking.
>> "-rpath" option is to add a path for library search - so that binder
>> can locate the shared object in the specific directory. If no -rpath
>> is specified, "-L" is used for runtime search as well.
>> -Sundar
>> On 22/01/19, 12:01 AM, Jorn Vernee wrote:
>>> Hi,
>>> I've recently updated the instructions for using libraries on Windows. For python the jextract example I gave was:
>>>    jextract -l python27 -o "python.jar" -t "org.python" C:\Python27\include\Python.h
>>> I'm lacking an `-L` option here (for specifying library directories) since the contents of PATH seems to be added to java.library.path by default, and this is presumably also how jextract is able to load the library. But, since I'm not using an `-L` option, SymbolFilter is not checking if the symbols are in the python27.dll [1]
>>>    private void initSymChecker(List<String> linkCheckPaths) {
>>>        if (!libraryNames.isEmpty() && !linkCheckPaths.isEmpty()) {
>>>            // ... init symChecker
>>>        } else {
>>>            symChecker = null;
>>>        }
>>>    }
>>> (linkCheckPaths comes from the -L option values)
>>> This behaviour is somewhat unexpected. At least a warning that missing an `-L` option will turn off symbol checking would be nice.
>>> We could also add the paths in `java.library.path` to the list of link check paths in jextract [2]. That would mean that the symbol checker would run for the example command.
>>> What do you think?
>>> Jorn
>>> [1] : http://hg.openjdk.java.net/panama/dev/file/eaca2d16b80b/src/jdk.jextract/share/classes/com/sun/tools/jextract/SymbolFilter.java#l89
>>> [2] : http://cr.openjdk.java.net/~jvernee/panama/webrevs/jlibpath/webrev.01/