[nicl] Adding -rpath option to jextract tool

[Henry Jen]

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