If you want to codesign and notarize your binary from linux, you can also use rcodesign[0]! I've been using it in production for about a year, and it's been working great so far.
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/<hash> (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.
zig fetch fills the hash for you, or simply omitting .hash in zon and the compiler tells it for you. I'm writing backend in zig and I have zstd directly from zon as a dependency.
You can specify your own linker if you want, mold is a very popular one, and cargo-zigbuild does the same behind the scenes with zig cc as the linker.
I did something similar a couple of months ago (or a year ago? I don't remember exactly). I managed to cross-compile to windows-msvc on Linux using Wine, there's a project that provides the scripts to make this easier, including the linker wrapper: <https://github.com/est31/msvc-wine-rust>. It was just for fun because Rust can already target windows-gnu and it'll use mingw64 linker.
Rust's approach to things is normally to provide the basic foundation and let the community build on top of it. I personally like this approach, but it also has this downside of people not knowing they may need an external/community built tool to accomplish what they want.
> I’m curious what the blockers are for rustc to cross-compile like zig does natively.
Zig ships all the bits you need for a C/C++ toolchain including things like the C library in some cases (IIUC).
Rust could use libclang to make a "rustc cc" just like zig's. But I get the sense that it is probably not a goal of the project to have this functionality.
That would solve the compilation problem, but there is more to create a working binary. For MacOS the official (and I believe only legal) way is to use a Mac with XCode installed for linking.
Now, you can download all the necessary files from a Mac and build a cross-compilation toolchain on your Linux system. I believe you could not legally distribute a project doing this and that is why these projects don't exist or are usually short-lived (with the notable exception of zig).
We will see how that goes for OP.
So, solutions like osxcross resort to shipping scripts that help you to acquire the necessary files and make that process easier.
The OP builds on osxcross, but is "batteries included".
zig has an even more difficult problem to solve because it tries to compile and link for many platforms. Shipping all the different requirements in their original form would make a zig distribution huge. So it does some clever magic I do not fully understand to create the necessary files from just the necessary subset of data. This reduces the size because there is overlap between platforms. It also means that they are not shipping the Mac files in their complete and original form and have gotten away with this legally so far.
At least that is what I believe is happening. I hope someone with more knowledge about zig could explain it better.
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.
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.
Rustup arch only adds support for static libraries (unliked objects), and craps out as soon as you try to build a binary.
Rust did not do the legwork that zig did to bundle libc and a working linker, and Cargo is exceptionally naive in its default configuration, so it won't even find a usable cross-linker on the system, nor even try the chronically-unfinished rustc-lld integration there is.
I could be mistaken, but I believe that installs a completely parallel toolchain which is relatively large compared with zigs approach of having all the platforms generatable from a single toolchain.
Great to see all of this work brought together like this.
I looked into some of these solutions earlier and the licensing status of doing this is pretty grey and likely violates some of the toolchain licenses.
For personal use, that's not really an issue. It's far easier than trying to get a decently performing OSX runner somewhere, and I don't see Apple caring at all.
Use caution if you are bringing this into a commercial environment.
Apple ships extra stickers with their logo in the box with a lot of their products, maybe slap one on your computer and see how far it gets you in court?
I used a Hackintosh for a number of years and Apple could have easily shut down the entire community with enough cease and desists. In fact there were engineers that helped provide valuable information.
They don't mind what people do for personal use. Just don't try and turn it into a commercial product.
Any source or further information for what makes you say there were engineers that that provided information? I always suspected some of the people in these communities were engineers but never discovered anything for my thoughts to make it past just being suspicions.
I'll plug some work I've been doing to (attempt to) enable cross compilation of Python wheels. I put together a small example [1] that builds the zstandard wheel, and can build macos wheels on linux and linux wheels on macos using zig cc.
macos wheels must still be adhoc signed (codesign) and binary patched (install_name_tool), so I re-implemented those functions in Python [2].
Currently I cross-compile the other way since the story is easier. Getting dependencies, etc. especially if you want something libssl is an annoying nightmare if you're trying to cross-compile targeting MacOS on a host on Linux. But if you're going the other way, very easy to use Docker.
The good part of this is that I can use a standard Linux host now to just build everything. Very nice!
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
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.
This vastly depends on how you intend to distribute your binaries.
I get away with distributing internal tools to my team completely ad-hoc signed, as long as I download them with cURL or SFTP. Downloading with a browser taints them, of course, and gatekeeper will prevent you from running them.
To be clear, it doesn't depend on anything. If SIP is enabled, you cannot run executables on ARM Macs without codesigning (they may be ad hoc signed, sure, but they still need to be signed). The executable will get killed immediately if you don't.
You can avoid gatekeeper problems by clearing the xattrs on the file. If they're internal you can also just distribute over a network share and it's not an issue.
Hm, need to give this* a try with NixOS cross compilation for macos. If I could pre-build nix packages for macOS developers on linux build hosts that'd be awesome.
This is really cool! I spent the time a couple years back to build a windows sysroot, but having a macOS one was on my mind for a while. Will definitley use
The penguin is holding the apple, unfortunately rather than commissioning an actual artist they've seemingly gone for AI art, so the penguin also has three arms. The left foot with the third arm there is also a bit... weird and deformed.
It’s a project with 20 GitHub stars which wraps up existing tooling to make a fairly niche need easier. The expectation that they’d commission an artist to produce a fun hero image for the readme seems a little odd.
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.
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 don’t in fact know that the model used to generate this was trained with art used without consent.
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.
Neither is "I'm not going to contribute a damned thing, but nonetheless the team behind this free product needs to spend more time and/or money to make me happy."
If you don't like the logo, well... that sounds a lot like a personal problem to me.
> 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.
[0]: https://gregoryszorc.com/docs/apple-codesign/stable/