I already use depstar to generate an uberjar for an application. I would like to aot the uberjar and added the :aot true and :main-class project.core but got an error:

Syntax error macroexpanding at (type.cljc:1:1).
Caused by: Can't embed object in code, maybe print-dup not defined: clojure.lang.MultiFn@54a98358

Any pointer about what should I look for to fix this?

@mynomoto That sounds like a syntax error in your code.

What is that type.cljc file?

Lots of plumatic schema definitions, that depends on several other namespaces.

The only other noticeable thing is that we add some cheshire encoders for some classes on this namespace.

I will try to comment those

Comment the encoders makes no difference. Loading the file over a repl causes no errors.

you should try to compile your application with (compile 'your-main-namespace)

while ensuring that *compile-path* exists and is on your classpath

i.e., manually make an empty classes folder in your project, and then in a REPL run (compile 'project.core)

Ok, trying that. Thanks!

user=> (compile 'project-x.core)
  Execution error at project-core.schema.type/loading (type.cljc:1).
  Can't embed object in code, maybe print-dup not defined: clojure.lang.MultiFn@3705a85c
  

Looks almost the same, but maybe someone will understand something that I don't.

That means the problem is in your code, most likely some sort of syntax error (and nothing to do with depstar). So you'll have to start commenting out parts of that file to figure out where the error is.

If it's up on GitHub where we can take a look at it, we'll probably be able to pinpoint the problem faster.

It's a big private repository. I will follow your recommendation of commenting code until narrowing it, thanks. I suspected that it was not related to depstar but there is #aot 😉 Thanks!

Compiling each namespace is a good way to check for syntax errors if your editor isn't running a linter 🙂

After 2 namespaces of indirection and one rabbit hole I found the problem on one of our macros that is a def that keeps the metadata of the original var. Compiling each suspect namespace helped a lot. The jar is not working but this is another problem. Thanks!

Thanks for reporting back @mynomoto!