@hi895 the simplest way is to build within the docker container and copy the DNS dynamic .so
Have a look at this https://github.com/leafclick/pgmig/blob/master/Dockerfile
Thanks @katox! That looks interesting π For now I think I stick with the alpine-glibc approach but if the image size is really critical, that is definitely a neat solution!
Dev image size is critical? While building? Because this target image really just contains the shared libraries and the final graal native binary, nothing else.
I meant, copying all the shared libraries is a great solution to get a small FROM scratch
image. With alpine the image is probably a little bigger.
The reason for me to still stick with alpine for now is simply that the Dockerfile
has less lines of code and feels easier to maintain.. but itβs really cool that all it takes to run from scratch is copying those libraries π
Note that it is not totally safe to build a graal image on one system and run it against shared libraries of another. Slight incompatibilities or memory corruption would be hell to debug. Unfortunately you can't use static linking if you need DNS resolving.
hm I do use --static
β¦ https://github.com/jorinvo/prometheus-pushgateway-cleaner/blob/master/deps.edn#L22
or you refer to something else?
Yes, you can't use static linking, therefore -static
.
See https://github.com/oracle/graal/issues/571
Interesting, because that is not the issue I get. I use --static
. DNS lookup works as long as glibc is included in the final image.
If glibc is not included, I also donβt get a SEGFAULT. I get a UnknownHostException
.
Yes, it is in the linked issues, see https://github.com/oracle/graal/issues/1151
1πYes, that is exactly the issue I also came across π
I talked about the issue with Oracle guys. In the end they marked the whole "static linking with glibc" as an usupported case. Not just by them but GNU as well. So I ended up with something that's more or less the same for me minus some initial hunting of dynamically linked shared libraries. But if you stick with a stable distribution like stable debian they are very unlike to ever change.
That sounds like a good compromise, yes π Sad to hear the donβt plant to support this π The easy of creating static binaries is something I miss from writing Go π
I'm seeing an error "clojure.core$pr_on was unintentionally initialized at build time", which isn't in the call tree nor does initialize-at-build-time help. Has anyone seen this error before?
unfamiliar with that error.
native-image webinar: https://www.oracle.com/a/ocom/docs/dc/em/sev400037415-na-us-ow-cre1-ie1a-ev.html
Thanks for the info!