Fork me on GitHub

i've replicated the problem with using the chocolatey-based windows-sdk-7.1 -- attempts to build a native image result in the error mentioned here: -- this was in a windows 10 vm. will try a manual set up later.


looks like uninstalling the chocolatey windows-sdk-7.1 package and then manually installing the windows sdk makes things work out -- at least the build is proceeding further now.


@borkdude by modifying PATH on a machine where clj-kondo.exe did not work, i had success in getting it to work


i compared some dependency walker info for a clj-kondo.exe working in one vm with one that did not work on a host machine. some differences i noticed include: 1) the working side used dlls from openjdk for some things while the not-working side used dlls from powershell core 2) it didn't seem to be a case of the working side was finding more dlls than the not-working side -- if anything it looks like at least for the set of things satisfied by openjdk vs powershell core, the working side found less i tweaked PATH (so on windows, i guess this also affects how dlls are located...) for the not-working side so that it would pick up some dlls via openjdk instead of powershell core, and the result was that clj-kondo.exe started working.


@sogaiu that's promising. do you know which dll it is?


my current impression is that it's not clear whether the problem is a single dll -- a different set of dlls is being picked up so it may be more than one


i will try to see if dependency walker can export more info about the files -- i only saw paths when i did the comparison


so maybe this problem can be solved with scoop or chocolatey by setting a path to the right dlls or having a dependency on openjdk? (cc @rahul080327)


possibly -- don't know if you looked at the stackoverflow info on /mt vs /md, but my impression is that the choice the graal folks have made at the moment by not supporting static is one of the contributing factors to problems like this. i don't know if it's practical for them to support --static any time soon, but that seems like a better way to address the issue -- and get more folks being willing to test native-image.


iiuc, on windows, PATH affects which dlls get used by a program -- i think this explains why i kept seeing such varied behavior. installing other software in / uninstalling software from your environment can destabilize execution of existing software because that can lead to changes in PATH, which unfortunately can affect which dlls a program sees / uses.


if scoop or chocolatey can arrange to have a startup exe or script that sets PATH appropriately right before launching clj-kondo, may be that can address things?


maybe yes. I think Rahul mentioned something about an installer, that bundles dlls, but I don't know how that works


maybe it's best to wait for the GraalVM to bring more clarity around this


possibly - i think it might be good to give the graal folks some feedback though. two points i see as problematic for people to test out native-image on windows are: 1) the environment set up should be automatable (e.g. doable via appveyor and the like), 2) --static should be supported to eliminate dll-related issues, but also for deployment reasons.


sorry for the late chime in, the thing that I was mentioning to @borkdude was


this could be a (last ditch) way to package the generated exe along with the DLLs from whatever build env it was produced in


AFAIK, the exe should pick up the DLLs if they are in the PWD too


so if we can install the exe and DLLs in to say C:\Program Files\clj-kondo it should work i think


and NSIS is fully scriptable. can be packed onto appveyor


i remember using nsis -- i think there's also innosetup -- is the former preferred these days?


my exp is most with NSIS as it produced the most compatible setup.exe


and the fact that the scripting is quite scriptable


personally i dont see a fool proof way of getting this to work till we have a control of the kind of flags used by native-image when calling the linker i guess


apart from using a bundling installer. the good old wizard based windows setups 🙏:skin-tone-3:


also i may be woefully wrong as my windows muscles are getting rusty 😕


well, your windows muscules are probably less rusty than mine 🙂


btw, i came across this: may be there is some relevant info -- or there might be a better doc about dll search order


if the dlls are picked up from the same dir as the .exe, then it could also work with scoop which I think allows downloading dlls along with the main zip and places them in the same dir... not sure


so from @sogaiu’s link:

The search order is as follows:
- The directory from which the application loaded.
- The current directory.


so it may just work


most of my windows dev revolved around Qt, which had its fair weight of DLLs and it did work from the PWD of the exe


so if we can get clarity of which dlls those are, then I could try to add them to the scoop bucket for testing


so i guess one way could be: - install the 7.1 SDK - dump the dependency list - copy over the exe and the DLLs into a folder - pack it up


oh yes, just the entire thing as a .zip


yeah, an MVP could be as simple as a zip of the stuff


and the trust on the fact that we arent supplying malicious DLLs. (this is my old paranoia typing)


> oh yes, just the entire thing as a .zip Essentially thats what NSIS is with a more human, interacting and democratic way of installing


a lot of them show the path to the DLL too. can try zipping them?


I tried dependencywalker, but it was a bit overwhelming


yeah theres a lot of noise


i have a feeling we are gonna solve before they do


LOL. I don't have a Windows virtual machine right now because my work laptop had to go in for repair, and the current one has a limited disk. Isn't there something non-GUI that's available on appveyor maybe? I could give the GUI approach a stab, but not soonish


I can try that too but in a similar situation of limited disk space 😕


pretty active project! TIL


looks wayyy less noisy too


cool, we can mess with it on appveyor 🙂


yeah last time it just took 19 failed builds. have about 5000 more to go!


failed builds are cheap right?


yeah its time/build thats billed AFAIK


I was assuming this is free 😉


billed in the sense there is a limit


like CircleCI's 1000 build minutes per month


ah I didn't even know about that limit


@borkdude I'd suggest using the Appveyor UI to mess around as its way less roundtrips and time waste as making new commits


ok, I might try it, but currently I'm focusing on a different clj-kondo issue, namely inlining some deps and this breaks the tests 😕


apart from that, it's bloody hot here


Berlin's approaching 40 here. 🤯


That too when its the most vegan place i know 😛


(at least for what we're used to in NL ;))


@taylor I have inlined some deps (rewrite-clj) using mranderson. now I see that those files are also compiled by clj-native-image. somehow the protocol defined in one of those inlined files is unbound now:

Caused by: java.lang.IllegalArgumentException: Unbound: #'clj-kondo.impl.rewrite-clj.v0v6v1.rewrite-clj.node.protocols/Node is not a protocol
any ideas? the full output is here:


Hmm not familiar with the inlining thing but maybe something is being compiled out of order?


Is there a branch to play with?


it seems compiling out of order is the problem. I've got it working with an uberjar now it seems, so I might revert to that, least friction

👍 4

I’ll see if I can figure something out before I have to go write Scala at work haha 🥺


no worries, I can go on with my work using the uberjar. just fyi


I think (in-ns 'clj-kondo.impl.rewrite-clj.v0v6v1.rewrite-clj.parser.core) in that file might be tripping it up because I’m using but not sure yet


ah, you're doing static inspection?


by way of, yes


find-namespaces-in-dir returns different results if I comment that out, though it still doesn’t resolve the issue


probably a red herring — even if I remove that ns altogether it still fails


got past that particular error by just not using defprotocol+ but then I reach a different one about cognitect.transit$reader being unreachable, so I’m assuming there’s something pretty fundamentally broken about how this is getting AOT’d in clj.native-image :thinking_face:


regarding search order, i also found this: -- it has some reflections / observations regarding the previous link, plus other info.


cool, it seems putting them in the same dir via a .zip makes sense


i am not sure yet - trying to digest the list of exceptions.

Adrian Smith18:06:02

Has any one ever tried compiling a binary for alpine linux? using graalvm and native image?

Adrian Smith18:06:44

I've just seen an option for --static is that how to do it?