CRaC / example-lambda

16 stars 4 forks source link

Fedora: version `GLIBC_2.34' not found #4

Open jankratochvil opened 9 months ago

jankratochvil commented 9 months ago

Fedora 38 x86_64:

./crac-steps.sh s00_init
./crac-steps.sh dojlink ../crac-git/build/linux-x86_64-server-fastdebug/images/jdk
./crac-steps.sh s01_build
 ---> Running in 844b0eabff23
Successfully decoded 40702088 bytes                                            
/jdk/bin/jar: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by /jdk/bin/jar)
/jdk/bin/jar: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by /jdk/bin/../lib/libjli.so)
/jdk/bin/jar: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by /jdk/bin/../lib/libjli.so)
/jdk/bin/jar: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by /jdk/bin/../lib/libjli.so)
The command '/bin/sh -c /prepare-jdk.cmd.sh ;   cd /function/lib; /jdk/bin/jar -x -f aws-lambda-java-runtime-interface-client*.jar      aws-lambda-runtime-interface-client.musl.so         aws-lambda-runtime-interface-client.glibc.so' returned a non-zero code: 1

I expect it tries to run a host-build binaries in ubuntu:18.04. That cannot work.

rvansa commented 9 months ago

So you're using a JDK build executed on a newer glibc, and this will fail if running in older environment. Rather than #6 , have you considered building JDK in (older) container, too?

jankratochvil commented 9 months ago

So you're using a JDK build executed on a newer glibc, and this will fail if running in older environment.

Exactly.

Rather than #6 , have you considered building JDK in (older) container, too?

That would obviously work. But that is a bit complicated plus one will build a JDK only for this example-lambda/ and the build is not useful for later real use.

example-lambda/README.md states one should download a binary from Github but running random binaries from internet I find insecure. That will make from Linux the same what became Windows.

(1) It could either build its own CRaC in the same container it is using for the example run. (2) Or it could detect which container to use from the host OS where the JDK was built. (3) Or it would not use any containers. I do not see what they are good for even in this case.

This option is not possible as the container is being run --privileged: Or it could download a prebuilt CRaC JDK as the host OS should be secured from the container.