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

[Jorn Vernee]

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

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/