[nicl] Adding -rpath option to jextract tool

[Sundararajan Athijegannathan]

Updated: 
http://cr.openjdk.java.net/~sundar/jextract_rpath_option/webrev.01/index.html

Changes:

* Restored -L option with a FIXME comment.
* Added a FIXME comment to LdLoader for initialization of usr_paths. 
Renamed getUserClassPath to be getUserLibraryPaths.
* Refactored library search in NativeLibarayImpl to findLibraryPath method.

Thanks,
-Sundar

On 16/02/18, 7:40 AM, Sundararajan Athijegannathan wrote:
> Yes, I removed the "link time" -L option because jextract was not 
> doing anything with it - other than option help message. I can restore 
> "-L option help" part with a FIXME comment. i.e., if we want to 
> check/validate symbol existence during 'jextract phase' in future.
>
> Henry: I'll refactor NativeLibraryImpl as you suggested.
>
> Thanks,
> -Sundar
>
> On 16/02/18, 2:01 AM, Henry Jen wrote:
>> Thanks John to bring up the important distinction on -L and —rpath(-R).
>>
>> The -L  option is linking phase(tooling), where the intention is to 
>> validate the symbol does exist in the library, we have the option but 
>> not yet implement it. —rpath is for binder to actually load the 
>> library. As current implementation, —rpath is the right option. On 
>> some system, -L is added to rpath unless —rpath is explicitly specified.
>>
>> -L was added because jextract as a tool more likely the role of 
>> compiler/linker, and we can carry over the value into binder as pass 
>> over the value to —rpath.
>>
>> There should probably have other mechanism to modify runtime solution 
>> as well, which we already have -Djava.library.path similar to 
>> LD_LIBRARY_PATH.
>>
>> Cheers,
>> Henry
>>
>>> On Feb 15, 2018, at 10:25 AM, John Rose<john.r.rose at oracle.com>  wrote:
>>>
>>> On Feb 15, 2018, at 10:18 AM, Henry Jen<henry.jen at oracle.com>  wrote:
>>>> I see we removed -L and added —rpath. I wonder why not both? We 
>>>> tried to use same options as gcc where C developers is likely 
>>>> familiar with.
>>> Yes, we want both.  Every linker-related option should be saved 
>>> somehow.
>>>
>>> It's OK to parse out specific options with portable semantics, but 
>>> we also
>>> want a string (or array of strings) which is a grab-bag of random 
>>> stuff that
>>> is known at jextract-time to be relevant to the linker, but doesn't 
>>> have a
>>> portable meaning.  Dropping it is not usually the right answer; passing
>>> through and hoping that the system-specific binder knows about it is
>>> more like the right answer.
>>>
>>> The -L vs. -R distinction is of phase:  Link time vs. run time.  
>>> Since the
>>> binder does aspects of both, we need both.  But the distinction should
>>> also be preserved; they can't be dumped into the same bucket.  That
>>> way if we ever do AOT of Panama bindings, we will know which paths
>>> to look at, during AOT time, which may include operations of linking
>>> (but not runtime resolution).
>>>
>>> — John