Hacker News Reader

Comment by bhouston | Hacker News Reader

Nice! I would expect that it was relatively straight foward given that Blender is native on MacOS ARM and also iOS ARM?

Blender is just so nice to use these days.

For us (Wireshark) the difficulty wasn't with our own codebase, but with getting our dependencies ported over. Most libraries built just fine, but some strongly assumed that "Windows" meant "x86".

It's not just Windows, either. Many libraries (particularly ones that use Autotools) are absolutely blind to the notion that you might want a universal binary on macOS.

When we ported OpenJDK to macOS, I ended up producing a universal binary by having the Makefile run itself to produce HotSpot twice, and then gluing them together with `lipo` afterwards. There isn't really a better way when the actual project configurations are different.

IIRC it was eventually removed because nobody else needed to do such a thing so it was hard to maintain.

Sure. How else would you build a universal binary then? Given the low-level nature of the language not many tasks can be usefully shared between different architectures.

For plain C/C++ you can just pass `-arch x86_64 -arch arm64` to clang. CMake takes care of this for you if you specify `CMAKE_OSX_ARCHITECTURES=x86_64;arm64` and IIRC Meson has similar functionality.

TIL. I didn't know clang supports this natively.

Clang is natively a cross-compiler. Pass in --sysroot and a corresponding valid sysroot tree for any micro architecture/platform (arm-eabi, macOS, Windows MSVC, PowerPC, Alpine Linux with musl, you name it) and Clang will happily retarget the binary to the correct target platform.

Apple has supported that ‘-arch’ option in their GCC/Clang since at least the PPC->Intel transition, maybe even earlier (PPC64? NeXT/OPENSTEP?)

Yes, since NEXTSTEP.

That would be NeXT, and their GCC fork.

I assume this is faster than doing two separate builds, because it can skip certain steps of the complier pipeline, and only the items that are arch specific (codegen, probably others) are done twice?

They can't really share anything since the preprocessor stage can be different.

How much work does clang have to do for this sort of thing (as opposed to llvm). Hypothetically could we start distributing programs in llvm ir, and compile that locally to ARM, x86, risc-v, or whatever else?

I mean, no, that’s silly, right? But it would be kind of neat…

llvm-ir is not architecture independent, even excluding issues like the C pre-processor.

And Linux ARM, I would expect?

Yes, Blender was native on my ARM phone several years ago already - until its GPU requirements went up.

There was a talk on this at Blendercon last year!: https://www.youtube.com/watch?v=xVn8wQ3tKxA

> also iOS ARM?

Wait WHAT?! Since when?

It was announced two weeks ago. Details: https://youtu.be/JFtvdItYNBU

I think it has built for years. There just hasn't been a usable UI.

The video is just the author commenting https://code.blender.org/2025/07/beyond-mouse-keyboard/ (with a bit of context)

Reply on news.ycombinator.com