<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <p>Uhm... I'm not sure I get all the moving parts here.</p>
    <p>The jextract code here is loading "libssl.dylib". E.g. Jextract
      is not trying to directly load an unversioned "libcrypto.dylib".
      Correct?</p>
    <p>If that's correct, the problem seems to be in _which_
      libssl.dylib ends up being loaded by jextract. E.g. perhaps the
      version picked up by jextract has a dpeendency on an unversioned
      libcrypto.dylib, which then results in the error you are seeing.</p>
    <p>But, jextract (and the library lookup) are merely asking the
      dynamic linker what to load, given a library name. That is, the
      code jextract generates will result in "dlopen("libssl.dylib")".
      Does it means that, on MacOS, that dlopen command leads to a
      crash? That seems surprising (as I'd expect the dynamic linker to
      be configured in a way that makes sense), but I see something
      similar documented e.g. here:<br>
    </p>
    <p><a class="moz-txt-link-freetext" href="https://github.com/sergot/openssl/issues/81">https://github.com/sergot/openssl/issues/81</a></p>
    <p>It seems like the solution is to pass a versioned library name to
      dlopen (e.g. using jextract option `-l :<code class="notranslate">libssl.46.dylib`).
        E.g. I don't think you can use the same library lookup for both
        Linux and MacOS. So, if you want to share code between MacOS and
        Linux you would have to manually tweak the generated code to do
        different things depending on the platform. Or, you could keep
        using -Djava.library.path (e.g. by passing
        --use-system-load-library to jextract).<br>
      </code></p>
    <p>Maurizio<br>
    </p>
    <div class="moz-cite-prefix">On 13/02/2024 19:08, Rémy Maucherat
      wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:CANwj8ZraXzSrxPzLCyuVbxOOWQcsmgi8HWrc5aN8E2Svj1VUEA@mail.gmail.com">
      <pre class="moz-quote-pre" wrap="">On Thu, Feb 8, 2024 at 4:00 PM Maurizio Cimadamore
<a class="moz-txt-link-rfc2396E" href="mailto:mcimadamore@openjdk.org"><mcimadamore@openjdk.org></a> wrote:
</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">
On Wed, 7 Feb 2024 16:18:45 GMT, Maurizio Cimadamore <a class="moz-txt-link-rfc2396E" href="mailto:mcimadamore@openjdk.org"><mcimadamore@openjdk.org></a> wrote:

</pre>
        <blockquote type="cite">
          <pre class="moz-quote-pre" wrap="">Historically, jextract has always used `System::loadLibrary` and `System::load` to load libraries specified via the `-l` option. This is suboptimal, as in the most common case, such libraries will be installed using e.g. `apt`, in which case `System::load/loadLibrary` is of little use, as it cannot find libraries in path known to the dynamic linker.

This patch changes the default for library loading to use `SymbolLookup::libraryLookup` instead. That is, in absence of any other options, each library provided via `-l` will create a new `SymbolLookup::loaderLookup`, associated with the library arena.

The `-l` option also supports a new disambiguation mechanism, borrowed from the gcc linker options - that is, if the library name starts with `:`, what follows is parsed as a path. Otherwise, we assume it's a library name, and we add prefix/suffix, using `System::mapLibraryName` before creating the lookup.

In cases where the old behavior is preferred (e.g. if libraries to be loaded sit in `java.library.path`) a fallback option has been provided, namely `--use-system-load-library`.

Regardless of the options used, the header class will feature a composite lookup. Inside this lookup we find:

1. one or more library lookup (one for each `-l` option)
2. the loader lookup
3. the native linker's default lookup

When `--use-system-load-library` is used, (1) is empty, and a static initializer block with the corresponding calls to `System::load`, `System::loadLibrary` is added instead.
</pre>
        </blockquote>
        <pre class="moz-quote-pre" wrap="">
This pull request has now been integrated.

Changeset: 456632df
Author:    Maurizio Cimadamore <a class="moz-txt-link-rfc2396E" href="mailto:mcimadamore@openjdk.org"><mcimadamore@openjdk.org></a>
URL:       <a class="moz-txt-link-freetext" href="https://git.openjdk.org/jextract/commit/456632df2e0b00a3f0fd5714b020d00f90c41804">https://git.openjdk.org/jextract/commit/456632df2e0b00a3f0fd5714b020d00f90c41804</a>
Stats:     176 lines in 32 files changed: 91 ins; 18 del; 67 mod

7903654: Jextract should use library lookup
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
With that change in place, the code to load OpenSSL now looks like:
    static final SymbolLookup SYMBOL_LOOKUP =
SymbolLookup.libraryLookup(System.mapLibraryName("ssl"),
LIBRARY_ARENA)
            .or(SymbolLookup.loaderLookup())
            .or(Linker.nativeLinker().defaultLookup());

This works very well on Linux, where it improves things in some setups
(like the Tomcat CI runs which are now able to load OpenSSL).
However, on MacOS this seems to fail with:
"WARNING: <path to java executable> is loading libcrypto in an unsafe way"
And the JVM exits.

Given this: <a class="moz-txt-link-freetext" href="https://github.com/cl-plus-ssl/cl-plus-ssl/issues/114#issuecomment-770370592">https://github.com/cl-plus-ssl/cl-plus-ssl/issues/114#issuecomment-770370592</a>
It would seem it is trying to load the wrong "library" on that platform.

Rémy

</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">Reviewed-by: jvernee

-------------

PR: <a class="moz-txt-link-freetext" href="https://git.openjdk.org/jextract/pull/201">https://git.openjdk.org/jextract/pull/201</a>
</pre>
      </blockquote>
    </blockquote>
  </body>
</html>