Clojurians Log v2

What options are you using for building native-executable?

"--verbose"
"--no-fallback"
"-Djava.awt.headless=false"
"--report-unsupported-elements-at-runtime"
"-H:-UseServiceLoaderFeature"
"--no-server"

Could you kindly share the error message?

Please be aware that image in which HL builds your lambda is not exactly the same. HL uses oraclelinux for building ;)

I used my own docker image based on AL2 with the latest GraalVM to build it instead of the default HL image. I think my java.library.path is wrong

I’m not seeing the error message so i can’t help ;)

java.lang.UnsatisfiedLinkError: Can't load library: awt | java.library.path = [/opt/graalvm-jdk-22+36.1/lib/, /usr/lib64, /lib64, /lib, /usr/lib]
	at org.graalvm.nativeimage.builder/com.oracle.svm.core.jdk.NativeLibraries.loadLibraryRelative(NativeLibraries.java:141)
	at java.base@22/java.lang.ClassLoader.loadLibrary(ClassLoader.java:106)
	at java.base@22/java.lang.Runtime.loadLibrary0(Runtime.java:916)
	at java.base@22/java.lang.System.loadLibrary(System.java:2068)
	at java.desktop@22/java.awt.image.ColorModel$1.run(ColorModel.java:211)
	at java.desktop@22/java.awt.image.ColorModel$1.run(ColorModel.java:209)
	at java.base@22/java.security.AccessController.executePrivileged(AccessController.java:128)
	at java.base@22/java.security.AccessController.doPrivileged(AccessController.java:319)
	at java.desktop@22/java.awt.image.ColorModel.loadLibraries(ColorModel.java:208)
	at java.desktop@22/java.awt.image.ColorModel.<clinit>(ColorModel.java:221)...

Are you using anything AWT related?

yes

Lambda doesn’t have AWT included by default. You need to pack the library in the zip and use LD_PRELOAD as shown here: https://github.com/quarkusio/quarkus/issues/23998

Another option is to run your lambda in docker image.

https://docs.aws.amazon.com/lambda/latest/dg/images-create.html

ahhhh. I had assumed that the awt was included into the built output because libawt.so, libawt_headless.so, libawt_xawt.so etc appear in the /holy-lambda/build/native/ folder, which I believe is where native resources are copied prior to being packaged into the built binary, from where during execution they'd be dynamically linked

If the files are there it means that on AWS Lambda Environment they gonna appear under /var/task

meaning the first method you suggested could work

Yup, potentially it should work. If yes, then we can add this variable to bootstrap script :)

testing locally in the docker container of the image I used to build it I get

Fatal error reported via JNI: Could not allocate library name

Printing instructions (ip=0x000000000056c4ac):
  0x000000000056c3ac: 0xe0 0x03 0x1f 0xaa 0xfb 0x73 0x46 0xa9 0xfd 0x7b 0x4f 0xa9 0xff 0x03 0x04 0x91
  0x000000000056c3bc: 0xc0 0x03 0x5f 0xd6 0xee 0xbf 0x46 0xad 0xec 0xb7 0x45 0xad 0xea 0xaf 0x44 0xad
  0x000000000056c3cc: 0xe8 0xa7 0x43 0xad 0xe1 0x0b 0x46 0xa9 0xf9 0x6b 0x45 0xa9 0xf7 0x63 0x44 0xa9
  0x000000000056c3dc: 0xf5 0x5b 0x43 0xa9 0xf3 0x53 0x42 0xa9 0x00 0x00 0x1b 0xcb 0x00 0xfc 0x43 0xd3
  0x000000000056c3ec: 0x80 0xb3 0x00 0xb9 0xe0 0x07 0x00 0x32 0x88 0x53 0x00 0x91 0x00 0xfd 0x9f 0x88...
(very long dump leading back to the original stacktrace above)