[External] : Re: Making the foreign liner a required API

[Jorn Vernee]

Hi Peter,

 > the Solaris 64-bit library location isn't one that's in the default 
search list

It might be worth it to enhance the make/autoconf/lib-ffi.m4 script to 
look in the alternative library location as well. I recently added 
support for mac and windows as well [1], but prior to that, it really 
only seemed to be made for linux. So, there's probably still room for 
improvement.

 > I wonder if the correct approach might be to resolve what libffi.so 
points to rather than using the libffi.so.? pattern

This might work, but libffi.so doesn't always seem to be a link. I 
suggest trying to work out some improvements to the lib-ffi.m4 script, 
and then we can update the script. Perhaps we need a 
--with-libffi-libfile option that points to the exact library file.

Jorn

[1]: https://github.com/openjdk/jdk/pull/14446

On 23/06/2023 13:00, Peter Tribble wrote:
> 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/ 
> <https://urldefense.com/v3/__http://www.petertribble.co.uk/__;!!ACWV5N9M2RV99hQ!NiRy5Ij4KegR0sDzlN3kKFvBkuFBpB-9VnZ9hOLJFGdls5Woud_b_UF8RwCyGl0NDJL74dk7Ep0GUZPkPdl52F9T$> 
> - http://ptribble.blogspot.com/ 
> <https://urldefense.com/v3/__http://ptribble.blogspot.com/__;!!ACWV5N9M2RV99hQ!NiRy5Ij4KegR0sDzlN3kKFvBkuFBpB-9VnZ9hOLJFGdls5Woud_b_UF8RwCyGl0NDJL74dk7Ep0GUZPkPS1CLfGs$>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/porters-dev/attachments/20230623/d410dd4c/attachment.htm>