[foreign] does static forwarder generation has to depend on -l presence?

[Jorn Vernee]

Yes, we have to walk all modules loaded by the process. But, I imagine 
the internal implementation of RTLD_DEFAULT is pretty similar?

The LD_LIBRARY_PATH behavior doesn't apply to Windows either, since it's 
an implementation detail of dlsym, so using the default library really 
only gives someone access to libraries loaded previously by some other 
mechanism, e.g. System.loadLibrary.

I think it's not needed to worry about performance at this point. If 
better performance is needed the -l option can be used as well.

Jorn

Sundararajan Athijegannathan schreef op 2019-05-02 13:53:
> Default library on Windows is a bit costly, right? i.e., we have to
> walk all loaded modules? The API used is meant for debug use if I
> recall.
> 
> -Sundar
> 
> On 02/05/19, 5:00 PM, Jorn Vernee wrote:
>> I think there was some caution when they were added, but over time we 
>> have started relying on static forwarders more and more. I think it 
>> makes sense to always generate the static forwarders. The generation 
>> can always be turned off again using the command line option if 
>> needed.
>> 
>> Jorn
>> 
>> Maurizio Cimadamore schreef op 2019-05-02 12:50:
>>> Hi,
>>> as I was playing with some stdlib examples, I noted that jextract was
>>> not generating any static forwarder for me. I was then reminded that
>>> static forwarders are only emitted if some library is passed via the
>>> -l option.
>>> 
>>> Is this too strict? After all, we have a 'default' Library that we 
>>> can
>>> use as resolution context, which will pick up anything loaded by the
>>> VM (which also includes things in paths specified in sys variables
>>> like LD_LIBRARY_PATH). So, would it make sense to relax static
>>> forwarder generation so that, in the absence of -l, it will just use
>>> the default library?
>>> 
>>> That would improve usability in certain cases.
>>> 
>>> Maurizio