Live data from Hacker News

Show HN: macOS-cross-compiler – Compile binaries for macOS on Linux

github.com

41–50 of 76 posts

Re: Show HN: macOS-cross-compiler – Compile binaries for macOS on Linux

#41

Earlier quoted context omitted.

The link is about making Linux binaries on MacOS, which works because almost everything to build for Linux is already on OSX. The other way around it's not true. A Linux system does come neither with the OSX SDK nor the Apple patched llvm linker. I believe at least part of the required files cannot be legally distributed with a Linux system, but I might be wrong on that.

It appears you’re right, thank you! I’m very surprised there isn’t a llvm linker available, minus all the foundation kits that rust doesn’t need.

The llvm linker is a cross-linker in principle. I think it is more about the specialities that Apple needs, like code signing.

Re: Show HN: macOS-cross-compiler – Compile binaries for macOS on Linux

#42
post #33

Earlier quoted context omitted.

These are volunteers providing hundreds (at a guess) of hours of unpaid labor to a project they're giving away for free. You also expect them to pay an artist out of their own pockets? Maybe an artist (for example, you) could donate his or her time and provide them with a better logo for free.

Why is this a defense for them using the labor of non-consenting artists to generate a crappy header image? Surely they could ask an artist to volunteer their time just as they volunteered theirs?

Please feel free to open a PR replacing the image with one from a volunteer.

I'm more than happy to make to make the switch and give credit to a proper artist if there's one willing to work for free.

Re: Show HN: macOS-cross-compiler – Compile binaries for macOS on Linux

#43
post #33

Earlier quoted context omitted.

Why is this a defense for them using the labor of non-consenting artists to generate a crappy header image? Surely they could ask an artist to volunteer their time just as they volunteered theirs?

Random generated images slapped up in a context where there’s clearly no competing commercial interest just seems like a really silly hill to have this fight on. Even if you take a hard line on the debate on model training data, this is an utterly harmless case, and certainly not worth the gut punch threads like this cause to someone who is just trying to share their open source project with the community. Also, you…

This is an internet forum, there's no hill here. It is the lowest possible stakes to have this discussion imaginable.

It is just as easy to grab some CC-licensed images and throw them together in an image editor, like nearly every other FOSS project does at this stage.

Re: Show HN: macOS-cross-compiler – Compile binaries for macOS on Linux

#44

Earlier quoted context omitted.

Why would it? You can cross compile for macos with the go toolchain on Linux too and that doesn't even require an additional compiler. Just GOOS=darwin GOARCH=arm64 and then the regular command. Apple can't regulate everything

If you need the macOS SDK, then you need to obey the developer licensing rules. Does this need the SDK?

Only if you're using cgo. If you're building native Go code, the Go compiler is fully self-contained and can target any supported platform from anywhere -- macOS from Linux, Linux from Windows, Android from FreeBSD, you name it.

Re: Show HN: macOS-cross-compiler – Compile binaries for macOS on Linux

#45
post #7

I wonder if it will compile natively to arm instructions or rely Rosetta on host machine to perform translation

> A cross compiler is a compiler capable of creating executable code for a platform other than the one on which the compiler is running. For example, a compiler that runs on a PC but generates code that runs on an Android smartphone is a cross compiler.

https://en.m.wikipedia.org/wiki/Cross_compilation

So compile on Linux, run on macOS without Rosetta

Re: Show HN: macOS-cross-compiler – Compile binaries for macOS on Linux

#47

Earlier quoted context omitted.

It appears you’re right, thank you! I’m very surprised there isn’t a llvm linker available, minus all the foundation kits that rust doesn’t need.

The llvm linker is a cross-linker in principle. I think it is more about the specialities that Apple needs, like code signing.

Ah. For what it's worth, those have been reverse engineered and copied elsewhere. I maintain a project that does cross-compiled macOS builds and our own signing on Linux.

Re: Show HN: macOS-cross-compiler – Compile binaries for macOS on Linux

#48
post #29

Speaking of cross compilers - I was able to use the zig toolchain in order to cross compile for macos apple silicon, arm Linux, windows x64, windows arm and x86_64 Linux musl (statically linked). It's super handy and works as a drop in.

I'm commenting to add a critical mass around Zig. If you are prisoner of CMake, autoconf, templates, makefiles, etc.. please try the Zig toolchain for your c/c++ projects. It is worth every second of investment

I’m intrigued. Do you have a starting point? And how does it handle if I need to integrate with another language as well, like Swift?

Re: Show HN: macOS-cross-compiler – Compile binaries for macOS on Linux

#49
post #14

The problem with this is licensing: the macOS SDK license says that it's only to be used on an "Apple-branded computer". That said I wonder what Apple would do if this is used outside of that case...

Nothing unless they can know for sure your machine is not a mac running Linux.

Re: Show HN: macOS-cross-compiler – Compile binaries for macOS on Linux

#50
post #29

Speaking of cross compilers - I was able to use the zig toolchain in order to cross compile for macos apple silicon, arm Linux, windows x64, windows arm and x86_64 Linux musl (statically linked). It's super handy and works as a drop in.

I'm commenting to add a critical mass around Zig. If you are prisoner of CMake, autoconf, templates, makefiles, etc.. please try the Zig toolchain for your c/c++ projects. It is worth every second of investment

Zig build is somewhat poorly documented currently, which can lead to some annoyance (also some other annoyances with dependency hashes), but in my experimentation:

Dependencies in build.zig.zon are downloaded in to ~/.cache/zig/p/ (incidentally, this means you need to mangle the hash if you are copying and pasting the hash for a dependency, at least currently. Dependency hashes are a sore spot tbh, and needs to be better)

Then when you are using said dependency in your build.zig, the function provided will refer to that source artifact in .cache.

At least this seems to be the case. I write a decent amount of zig, but haven’t dove too much in to the build system till recently, when I tried (and failed due to translate-c bugs), to get some C libraries added to zig using only zig build.

Post reply on HN