W dniu 22.10.2021 o 11:37, Jan Palus pisze:
> On 22.10.2021 10:44, Jan Rękorajski wrote:
>> Ah, it wasn't icedtea but openjdk8 that was installed on i686 and x86_64.
>> I'm uninstalling it and blocking in poldek on builders so that we have
>> only openjdk11 installable there.
> Currently openjdk8 requires either JDK 1.7 or 1.8 for build, I guess we
> can patch it and try to build with openjdk11, no guarantees it would
> work though. Not sure what is the difference but I had no issues
> building openjdk8 with openjdk8 and glibc 2.34 on
> x86_64, aarch64 and armv7hnl. I'll try to reproduce in fresh VM.

For me our openjdk8 from ftp hangs on just doing "java -version". Not
always. Sometimes I need to run that 5-10 times but I do get the hang
easily. kernel 4.9.194, glibc 2.34, x86_64, vserver guest

while (true); do date; java -version; done

openjdk version "1.8.0_302-ga"
OpenJDK Runtime Environment (build 1.8.0_302-ga-1)
OpenJDK 64-Bit Server VM (build 25.302-b1, mixed mode)

Build Date  : pon, 2 sie 2021, 16:46:33

Doing the same on kernel 5.15.2 (VM on proxmox) and -version works.
4.4.279 on vserver host, glibc 2.34 - works.
4.4.279 butin vserver guest, glibc 2.34 hangs.
4.4.279 but glibc 2.33 in vserver guest - works.

openjdk9- also hangs in vserver guest with glibc 2.34
openjdk10- works
openjdk11-11.0.13-1.x86_64 works

So vserver guest + glibc 2.34 + openjdk 8 and 9 is hanging on futexes.

Easy way of testing if you don't have glibc 2.34 installed:
- install openjdk8 from ftp (--nofollow --nodeps can be useful to
prevent in dragging latest nss and thus glibc 2.3 - only working "java"
binary is needed)
- copy 2.34 *.so libs to some path
- patchelf --set-interpreter
- run: while (true); do date;
LD_LIBRARY_PATH=/path/to/glibc-2.34-test-libs/ java -version; done

builders stopped using vservers on 7 november 2021 and use 5.x kernels

Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org )
pld-devel-en mailing list

Reply via email to