But what happens is it just builds for my current architecture.
When I look at the buildGoModule derivation I can see that args are passed to the build:
Bu then they are overwritten by values from go. And they take precedence since // used to merge attribute sets. So how exactly is one supposed to cross-compile using this derivation?
But wouldn’t that pull in all of the build dependencies for that given platform? That doesn’t make sense. Why would I need to pull whole stdenv all other dependencies when I can just cross-compile with the Go compiler I already have. Seems silly and unnecessary.
Anything mentioned in buildInputs (whether you need that feature or don’t need it) needs to be available.
The dynamic linker is part of this, that you do not add it explicitely doesn’t matter, it is still required unless you use pkgsStatic, which again is yet another beast.
A default Go library is build under the assumption by the go compiler, that it will find the dynamic linker at /lib64/ld-linux-x86-64.so.2 or something. This is not a valid location for nix, this is why nix builds the full closure.
What kind of silly idea idea that. Nix is an extremely good build tool that’s used by many projects to build things not intended for use within Nix ecosystem. You can not use it for that if you’d like, but plenty people do use it like that.
I have never seen nix being used to create something that can be used without the nix ecosystem (ignoring that projects like nix-bundle exist, which just hide the nix store within a container like thing or proots)
nixpkgs, however, is not designed for this usecase, unless you count bundling-style solutions that use a container with a /nix/store at runtime. You’ll probably need to leave most of nixpkgs’ helper code behind if you want to get results that don’t expect a /nix/store on the deployment target.
It definitely can be used that way, but you’re going to need to stop using nixpkgs convenience functions and look at using the underlying derivation keyword from nix itself. See the nix manual. Also, you may want to make use of the allowedReferences attribute to ensure that you’re not accidentally holding onto any nix store references.
Also, although you can, of course, use build-time-only dependencies from nixpkgs, any runtime dependencies you’re on your own for.
Maybe you could try make a PR to change the buildGoModule helper, to not inherit the os/arch from go, but take them from args or fallback to the ones in go.
Anything that is build on top, inherits this purpose and mindset.
If you want to build something else, you need to write your own builders based on builtins.derivation.
You need to throw away a lot of convenient abstractions, that all are based on the assumption to stay within nix.
What remains left for you, is to use what is in nixpkgs as an equivalent of nativeBuildInputs, at least those that are unwrapped. Or if they are wrapped use the unwrapped originals, and wrap them on your own to still be able to find stuff provided by nix, but produce FHS compatible.
As much as I dislike docker, but to be honest, I think using docker will be much easier and therefore much cheaper!