This error can happen when you instantiate the logger in a Clojure namespace on the top level. Since top level expressions are executed at image build time, it will then also initialize the logger at build time

I'm not instantiating the logger anywhere intentionally--so maybe something with a library. When I disable call to mount/start-with-args in my -main function then I'm able to build the native executable successfully. The`mount`library does appear to be addressed by graal-build-time so I don't know why calling this function triggers the error. I have 2 defstates, one that calls a next.jdbc function, and one that calls a clj-http function. I assume the logger is instantiated somewhere between those elements.

mount relies on global state right?

which sounds like this may be the problem

Yes, I believe so (https://github.com/tolitius/mount#creating-state).

Attempting to build with the mount state refactored into atoms worked but with a warning that it requires JDK for execution (which is a different issue). Would the global state thing make mount strictly incompatible for inclusion in a native executable?

You could also use delays but same idea

I guess the packages registered by graal-build-time are dynamically determined and not necessarily supported in graalvm builds. I'll just get rid of mount for this application. Thanks for the help!

Unfortunately, I spoke too soon and am still getting the same LogFactoryImpl error after removing mount. I have no idea how I had a successful build when first refactoring out mount usages, as I cannot repeat it. Now, the error is given every time I call a function in -main that ultimately calls jdbc/execute! from the next.jdbc library.

How I usually approach is to try to make the smallest example possible that still reproduces the error, and then try to find a solution

Yeah, that's the line I'm pursuing. I suspect the issue may come from the https://ucanaccess.sourceforge.net/site.html#home jdbc driver I'm using with next.jdbc to connect to an MS Access database. Is it possible to configure the native-image build to force a 3rd party library to initialize a class at runtime? I don't know if that's the right question, but I'm not sure how to proceed from here.

You can only initialize at runtime if the instance isn't initialized already at build time which may be the case in your application

I'll probably fall back to just working with the .jar for now. It would be much nicer to distribute a faster, batteries-included native executable, but unfortunately that may not be possible, or at least not worth the trouble for this case.