I remember issues with shared libraries and the way the Jvm is bootstrapping. Forinstance not having a /proc causes trouble of this sort. But we have a /proc(we are using arch-chroot and a bind mount point).

Actually also original SUN java 7 segfaults with this glibc.Rebuilding glibc didn't help. So I'm pretty sure it's some protection thingygetting into the way of old Java JDKs (because they always pushed their limitsand did funny tricks in the past).

building on i686 (where openjdk8 still works) and using makepkg.conf with pentium4cflags gives a package with wrong architecture though, but running in a pentium4chroot if installed.

Though when I try to rebuild it with the 'cross-compiled' package in a pentium4chroot, I get:

checking headful support... include support for both headful and headless
configure: Found potential Boot JDK using configure arguments
configure: Potential Boot JDK found at /usr/lib/jvm/java-8-openjdk is incorrect JDK version (#); ignoring
configure: (Your Boot JDK must be version 7 or 8)
configure: error: The path given by --with-boot-jdk does not contain a valid Boot JDK
configure exiting with result code 1

Inside I have a hs_err_pid3361.log showing again the darn SI_KERNEL SIGSEGV.

So -mstackrealign in the glibc flags helps to realign the stack, so that 4 and 16 byte stackscan coexist, but Java generates it's own executable code, which doesn't respect that?Why should -mincoming-stack-boundary=2 help then?I'll test again a double compilation via working i686 chroot to pentium4 (with -mincoming-stack-boundary=2 in the PKGBUILD of javapenjdk), then see if it can rebuild itself in a pentium4chroot.