Making the foreign liner a required API

[Peter Tribble]

Thanks Jorn,

On Fri, Jun 9, 2023 at 11:28 PM Jorn Vernee <jorn.vernee at oracle.com> wrote:

> To incorporate the library (.dll/.so/.dylib) into the JDK, it is
> essentially just copied into the right folder of the built JDK image.
> Automatic copying can be turned on using the --enable-libffi-bundling
> configuration flag. In practice, I'm using `--with-libffi=<path to
> extracted bundle> --enable-libffi-bundling --enable-fallback-linker` to
> create a working JDK image.
>

I've been trying this on illumos/Solaris, and simply adding

--enable-fallback-linker

gets me a clean build against the system libffi.

Bundling is a little trickier. I need to be explicit, because the Solaris
64-bit library location isn't
one that's in the default search list, so

--with-libffi-lib=/usr/lib/amd64

would be the correct way to specify where to look. However, in practice
that fails because my system
has multiple versions of libffi.so installed for binary compatibility (I'm
not sure how common this may
be on other platforms), and configure fails like so

checking for libffi lib file location...
/var/tmp/ud/jdk21-jdk-21-28/build/.configure-support/generated-configure.sh:
line 144232: test: too many arguments
configure: error: Could not locate libffi.so.? for bundling in
/usr/lib/amd64

I think the way round this, for me, is to create a sacrificial bundle area
and point the build at that,
but I wonder if the correct approach might be to resolve what libffi.so
points to rather than using
the libffi.so.? pattern, which might match multiple things, and will break
if the FFI shared library
version ever grows to double digits.

Thanks,

-- 
-Peter Tribble
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/porters-dev/attachments/20230623/3c2e15f5/attachment.htm>