This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-09-19
Channels
- # announcements (5)
- # asami (7)
- # aws (10)
- # babashka (10)
- # beginners (49)
- # calva (12)
- # cider (5)
- # circleci (1)
- # clj-kondo (25)
- # clj-yaml (14)
- # clojars (5)
- # clojure (134)
- # clojure-europe (142)
- # clojure-france (3)
- # clojure-nl (1)
- # clojure-norway (4)
- # clojurescript (10)
- # cursive (8)
- # datomic (19)
- # emacs (11)
- # fulcro (8)
- # graalvm (29)
- # honeysql (7)
- # jobs (4)
- # jobs-discuss (9)
- # lsp (196)
- # obb (4)
- # off-topic (40)
- # pathom (4)
- # releases (4)
- # remote-jobs (3)
- # shadow-cljs (16)
- # sql (25)
- # squint (2)
- # tools-deps (12)
- # xtdb (7)
- # yada (4)
Hi everyone,
We're currently trying to build a native image out of our clojure application but we're running into some bumps.
If we build with native-image [ARGS] --initalize-at-build-time
it works like a charm but we get the warning that --initalize-at-build-time
will be deprecated in the future, so obviously we are trying to avoid using the global flag. However this raises a problem.
We use clj-easy
to manage the packages for build time initialization registry but that library wont register single segment packages which leaves us with the following problem:
[clj-easy/graal-build-time] WARN: Single segment package found for class: primitive_math__init.class. This class has no package and it will not be added to the result packages.
And causes the build to fail:
2 fatal errors detected:
Fatal error: org.graalvm.compiler.debug.GraalError: com.oracle.graal.pointsto.constraints.UnsupportedFeatureException: No instances of primitive_math$_LT__LT_ are allowed in the image heap as this class should be initialized at image runtime. To see how this object got instantiated use --trace-object-instantiation=primitive_math$_LT__LT_.
Fatal error: org.graalvm.compiler.debug.GraalError: com.oracle.graal.pointsto.constraints.UnsupportedFeatureException: No instances of primitive_math$ns_wrapper$fn__6326 are allowed in the image heap as this class should be initialized at image runtime. To see how this object got instantiated use --trace-object-instantiation=primitive_math$ns_wrapper$fn__6326.
Does anybody have an idea how to include primitive_math
manually to --initalize-at-build-time
? We tried --initalize-at-build-time=primitive_math
and some variations to it but with no success.
Thanks in advance!@rick.suijkerbuijk Yes, use primitive-math
from here: https://github.com/clj-commons/primitive-math/tree/master/src/clj_commons
It now has a multi-segment namespace
Forgot to mention, we do not use primitive-math
ourselves but our lancaster
library uses it which causes a cascading effect
@borkdude Lancaster depends on the latest 1.0.0 version already
(Also: if the version was the problem, I wouldn't understand why the global --initalize-at-build-time
does work)
(Oh, you mean upgrade to the version of the master branch perhaps?)
If the Lancaster library still requires the single segment namespace that won't help. You need to avoid loading that
but then the question how come the global --initalize-at-build-time
manages to catch this and if you try to feed it by hand it wont register?
Because you need to give it either class names or regexes and those assume a package name. Single segment namespaces compile to classes without packages
so in other words there's nothing really to point to - manually, and the global flag just catches everything it comes across?
Ahh, right. So if we upgrade to the master
version of primitive-math
which has a multi-segment namespace, we can point to it manually?
you don't need master, 1.0.0 has those multi-segment namespaces and if you use those rather than the single-segment one, you don't need to do anything manually
Weird, since 1.0.0 is the version being used.
[clj-easy/graal-build-time] WARN: Single segment package found for class: primitive_math__init.class. This class has no package and it will not be added to the result packages.
But the plugin still complains about the single segment package.I think my level of understanding of the basics is insufficient. Lancaster does use 1.0.0 (the one you claim is multi-segment). Or is the single namespace segment still accessible in that version (and are you then saying that perhaps Lancaster still uses that)?
Yes it is. For backwards compatibility. You need to move manually to the multi-segment namespace, there is no magic here
Alright, I finally understand why we seemed to be talking past one another. Thanks for clarifying
Hi, can anyone give me a hint on charset for native image? When I run a binary file compiled, the default charset is US-ASCII, and all the non-english symbols sent to stdout/stderr appear as question marks. Is it possible to change the charset with an argument?
I’m using a binary file compiled from Clojure in a cloud service where interaction goes through stdout (response) and stderr (logs). At the moment, I can only use english characters which is a bit inconvenient sometimes.
@igrishaev Have you tried -H:+AddAllCharsets
? https://www.graalvm.org/uploads/quick-references/native-image-quick-reference-v2_A4.pdf