Clojurians Log v2

I think it's a good idea to clean as part of building

what about (System/getProperty "java.home")

/Library/Java/JavaVirtualMachines/graalvm-jdk-17.0.11+7.1/Contents/Home

how does cc determine the target architecture?

Ok, I have created this java class: https://gist.github.com/RokLenarcic/ee0bbb9c7b3d4310efb16b662bf22ecc When I run it:

Apple clang version 15.0.0 (clang-1500.1.0.2.5)
Target: arm64-apple-darwin23.5.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
Hello world!

but if I do clj in a folder with no deps, then I do the same via sh call, then I get x86

how it picks which to use is based on some sort of context

and what about java.home from the java class?

as far as I understand if process runs in x86, then subprocesses all chose x86

my vague working theory is some how clj is picking a x86_64 jvm, and somehow that context bleeds through

so you can check if the java clj is running is the same as the java you get by just calling java

So Java run also has Java home: /Library/Java/JavaVirtualMachines/graalvm-jdk-17.0.11+7.1/Contents/Home

I suspect something like Git it uses switches context to Rosetta

https://github.com/mozilla/sccache/issues/2093 maybe interesting

that is, I think you're on the right track with considering something else that's causing the rosetta switch

I think java and git are the only things tools.build itself ever shells out for

and by default it's just assuming "java" and "git" on the path

roklenarcic@Roks-MBP-2 production % which git        
/usr/bin/git
roklenarcic@Roks-MBP-2 production % file /usr/bin/git
/usr/bin/git: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64e:Mach-O 64-bit executable arm64e]
/usr/bin/git (for architecture x86_64):	Mach-O 64-bit executable x86_64
/usr/bin/git (for architecture arm64e):	Mach-O 64-bit executable arm64e

git is dual executable

same as clang I assume

roklenarcic@Roks-MBP-2 production % file /usr/bin/cc
/usr/bin/cc: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64e:Mach-O 64-bit executable arm64e]
/usr/bin/cc (for architecture x86_64):	Mach-O 64-bit executable x86_64
/usr/bin/cc (for architecture arm64e):	Mach-O 64-bit executable arm64e

will clj always run git?

no

it runs it if you use a git dep

if you export GITLIBS_DEBUG=true it will print any git commands it's running (and if you see nothing, then it's none)

hm ok but I just ran raw clj in an empty folder and (sh/sh "cc" "-v") still printed x86 and (println (System/getProperty "os.arch")) returns arm.

bizarre

you can also export GITLIBS_COMMAND to specify a different path to git if needed

tools.build is not using sh/sh btw (which is Runtime.getRuntime().exec(), it's using the Java process API ProcessBuilder.start() etc

I do not know if those differ in the jdk impl

seems like Runtime.exec() calls ProcessBuilder, so shouldn't be fundamentally different (other than the narrower feature set of Runtime.exec())

Hm does nobody else experience this?

I think the issue is that a lot of apps got carried over from my intel mac when I restored from a backup

I have to replace all my homebrew apps and also remove homebrew

I did similar migration recently from intel to m3. I manually reinstalled all of my Java installations to use the correct arch. I reinstalled a few homebrew things, but don't think I had to remove / reinstall everything

doesn’t x86 homebrew automatically pull everything in x86?

¯\(ツ)/¯

I lived through the Apple 68000 -> RISC swap and the RISC -> Intel swap and it always amazed me how much "just worked" but I know they did all sorts of weird stuff under the hood and I was never trying to build binaries for deployment elsewhere back then so I could most ignore the weirdness. Maybe something here will help you "persuade" it to use the version you want? https://developer.apple.com/documentation/apple-silicon/building-a-universal-macos-binary

hm a dependency of clojure in brew is rlwrap and that one is x86 on my system

a reinstall of clojure fixed this

interesting

probably could have deduced by comparing behavior between clj (uses rlwrap) and clojure (doesn't)