Thanks Jorn, On Fri, Jun 9, 2023 at 11:28 PM Jorn Vernee <jorn.ver...@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/