8 ms·

I really like what they've done for cross-compilation. Automatically selecting appropriate libc/crt implementation is such a relief. Compared to Zig, cross-com

by pornel 5y ago

I really like what they've done for cross-compilation. Automatically selecting appropriate libc/crt implementation is such a relief. Compared to Zig, cross-compilation in C/C++/Rust seems downright user-hostile: you have to obtain the correct cross-sdk, but it won't tell you which one, or how to get it (some combos don't even exist), or even where to put it. If you don't guess everything correctly, it will fail with inscrutable errors, or worse, only fail at runtime on the target machine.

pjmlp 5y ago
What this kind of stories always miss is that the host platform needs all system libraries for the target platform for anything beyond the basic examples using the standard library. E.g. try to cross compile Metal shading example for iOS from Linux with zig, or do a Win2D UWP rendering application from Linux with zig.
- zamadatix 5y ago
  I'm not sure what's really "missed", if you call a library other than the stdlib of course you're going to need to provide the appropriate headers/libraries for that as that's got nothing to do with a C compiler.
  - pjmlp 5y ago
    In general, it isn't so clear when these kinds of examples are posted. And to go back to my examples, headers and libraries alone won't make it, without the remaining toolchain to create the appropriate package.
    - zamadatix 5y ago
      Well for your particular examples UWP is C++/C#/a few others but it has no direct c binding and iOS APIs are all defined for Objective-C and Swift so sure, you're not going to get far with a C compiler before you even start thinking about a c cross compiler. If you want to cross compile C stuff e.g. a Win32 GUI app with Direct X or get OpenGL bindings for SDL though those all work just fine if you provide the SDK files same as you would compiling natively. The advantage being now you can do all builds from a single build instance just by feeding it the libraries and a target platform.
- flohofwoe 5y ago
  The Metal shader compiler is an unfortunate special case, because the bytecode and the Metal compiler tools are proprietary and locked up by Apple (there are precompiled binaries of the Metal compiler for Windows, but not Linux). The ball is definitely in Apple's court here, there's nothing any language project can do, except illegally reverse engineering Metal bytecode, which obviously isn't a good idea. The system API problem can be solved by shipping automatically generated API bindings (similar to what Microsoft does with the Rust bindings to the Windows APIs, a similar project for Zig is underway). Once those bindings exist, no Windows SDK is needed anymore and cross-compiling should "just work". PS: Zig actually ships with the mingw headers in the default installation (e.g. windows.h, d3d11.h, dxgi.h etc are all there), I haven't actually tried to cross-compile a Windows executable using the Win32 APIs though, but it looks like it should work already.
  - kevin_thibedeau 5y ago
    > illegally reverse engineering Metal bytecode Reverse engineering is legal in the US (unless bound by contract).
  - pcwalton 5y ago
    So does every new release of any Windows component require a new version of Zig? That doesn't seem sustainable.
    - flohofwoe 5y ago
      I don't actually know what Windows components mingw supports in detail and how often mingw is updated because of that, but I guess that the important Win32 APIs are stable. I suppose that the new APIs which are highly in flux could be supported by separate packages, like this: https://github.com/marlersoft/zigwin32 https://github.com/marlersoft/zigwin32)
  - Cloudef 5y ago
    The metal compiler probably could run with darling
- pcwalton 5y ago
  Right. Are you going to ship all Windows headers and import libraries to everyone, including DirectX, etc.? Are you going to keep them up to date with every new version of a Windows component? Are you going to ship parts of the macOS, or iOS SDKs? I don't see shipping all targets all the time to be a particularly scalable solution in general. When you start including all libraries necessary to develop actual apps, the download size will eventually get so big that people will complain. Just make it easy for developers to get the targets they need, but don't ship everything by default.
  - p0nce 5y ago
    > Just make it easy for developers to get the targets they need, but don't ship everything by default. It seems to be what Flutter is doing, and it must be a ton of work.
  - flohofwoe 5y ago
    I'd guess once Zig gets its package manager many target-specific packages can move out of the default installation.
    - pcwalton 5y ago
      Absolutely, which is exactly what I'm arguing for. :)
  - slimsag 5y ago
    I'd argue it's less about what the compiler does by default, but rather what it (and the community) enable. For Mach (the Zig game engine I'm working on), I have a Zig build script which fetches the required parts of the macOS and iOS SDKs from GitHub to enable cross compilation from Windows/Linux -> macOS. Zig's linker, zld, enables that to work easily.[0] For SDL.zig, they have also achieved cross compilation for most targets out of the box[1]. Contrast this to say, Go or Rust, where most GLFW and SDL bindings require mucking around with the system dependencies. It doesn't just work out of the box, I think that's really unfortunate and hope other languages work more towards painless installation of C-binding dependencies. [0] https://twitter.com/slimsag/status/1413770578494775298 https://twitter.com/slimsag/status/1413770578494775298 [1] https://github.com/MasterQ32/SDL.zig#support-matrix https://github.com/MasterQ32/SDL.zig#support-matrix
wyldfire 5y ago
> Compared to Zig, cross-compilation in C/C++/Rust seems downright user-hostile: This has been the status quo for so very long. Usually these projects are maintained by different teams. IMO musl is more accessible than glibc and that's part of what makes it easier to distribute. Arm and x86 coexisting for as long as they have is a factor, and so is Kelley's ambition to make this use case well-supported. nostdlib is also well-supported by Zig btw.
vvanders 5y ago
I would not include Rust in that list, in my experience rustup and cargo are miles ahead of C/C++ when cross compiling.
- steveklabnik 5y ago
  Personally, I see it in three tiers: Rust improved upon those experiences, but I still wish someone would implement what Zig has in rustc.
  - vvanders 5y ago
    Yup, fully agreed Zig stands above others here. Cross compiling C/C++ is just a special kind of hell. Each target always has some sort of bespoke toolchain and build environment constraint that add so much unneeded complexity.
  - pcwalton 5y ago
    I don't. We could approximate it by shipping all targets by default, but few really want that and the few who do can just install those targets with rustup.
    - nicoburns 5y ago
      Is it really few who want that? Anybody developing server software on windows or mac and deploying on linux could use this. Anybody developing cross-platform client software could use it. I'd guess that a lot of Rust developers currently do development on their target platform, but that's because cross compiling is such a pain. If it were as easy as zig or go then things might well be differen.
      - pcwalton 5y ago
        My x86_64 Rust libraries directory is 86MB. `rustup target list | wc -l` spits out 84 for me. The math doesn't add up.
        5y ago
DrBazza 5y ago
It's always a bit harsh comparing a 36 year old language with more-or-less full backwards compatibility, with a new language designed with the benefit of hindsight. That's not to say that it's impossible to do something like that in a C++ compiler but it's going to be more work than there is benefit. Tangentially related: https://twitter.com/__phantomderp/status/1416108650809241601 https://twitter.com/__phantomderp/status/1416108650809241601 C++ also tries to bring in modern programming research when it makes sense, but that also explains why it's like an octopus with extra legs nailed on.
- tialaramex 5y ago
  The octopus analogy seems especially appropriate. The thing about the legs on an actual octopus is that there's a bunch of local compute substrate in them, if you were to nail extra legs onto the octopus those are rubbish compared to its real legs which can think. For example, move semantics are a peg leg for the octopus. Should an octopus have a peg leg? I'm not a biologist of any sort, but my guess is "No". I can see why C++ wanted to add move (without this performance in some scenarios is just awful) and yet since C++ didn't start out having move semantics and can't give up backward compatibility it has to shoehorn them in with this awkward "hollowed out object" idea. The result is performance still isn't where it could be and the feature is unergonomic.
skohan 5y ago
I don't know much about cross compilation, but in terms of the Rust case, could part of it be the relative complexity of the language compared to Zig?
- woogley 5y ago
  `zig cc` cross-compiles C, not Zig.
  - skohan 5y ago
    No but I mean why the Zig cross compilation story is better than Rust according to this thread
    - woogley 5y ago
      I see. I'll let the real experts add some insight but I don't think language complexity has much to do with it, considering Rust compiles to an IR first anyway. And I would say Rust has a good cross-compilation story as it is. In 2016 (!) I managed to get Rust to compile my SDL2 game to a mipsel device that used a custom GCC toolchain (http://www.gcw-zero.com/develop http://www.gcw-zero.com/develop)
    - steveklabnik 5y ago
      Nothing about 'zig cc' is related to language semantics, it is entirely a toolchain feature. Language semantics do have some bearing on cross compiler difficulty, but IMHO it's not a major factor, especially within the sorts of languages that Rust and Zig are. The largest factor I can think of (compile-time code execution) exists in both Zig and Rust. It's possible I'm forgetting something, though. It doesn't exist in Rust because nobody has proposed it or implemented it, simple as that.
      - sobeston 5y ago
        I think Zig does cross compilation (ignoring for the moment, projects with C dependencies) better because it comes out-of-the-box with the libraries and headers needed to target a lot of systems. In Rust, you typically get additional toolchains via rustup, whereas Zig works on all of the targets with a single install.
zajio1am 5y ago
> cross-compilation in C/C++/Rust seems downright user-hostile: you have to obtain the correct cross-sdk, but it won't tell you which one, or how to get it (some combos don't even exist), or even where to put it. Since advent of multiarch, crosscompilation does not seem harder than regular compilation. Just install package with gcc for target arch and required libraries for target arch (using the same way as gcc and libraries for host arch).
sm_ts 5y ago
I've had to compile only a few times C/++ programs, and the experience can't be really compared to Rust (probably, to any other language :)). Lately I've cross-compiled a few times Linux/Windows programs, and the only thing I had to do (assuming that the underlying crates are compatible, and that the development libraries are in place, which is required for any language) was: rustup target add x86_64-pc-windows-gnu rustup toolchain install stable-x86_64-pc-windows-gnu That's all. Then one can compile with: cargo build --target x86_64-pc-windows-gnu I've also compiled for RISC-V, and it was the same procedure. There are surely issues with individual crates, and possibly with lower-tier targets, but to characterize this procedure as "user-hostile" doesn't make sense.
- pornel 5y ago
  That's true only for static libraries and pure-Rust projects. For executables and dynamic libraries Rust relies on system-provided linker (except nightly that can enable lld) and target libc already present on the OS (the nice part zig has, but Rust doesn't). Rust totally craps out if you try to make a binary or dylib and you don't already have cross-compilation toolchain on your OS. It's doable from a Linux distro that has cross packages and a GNU target. It's a PITA for anything else, including anything from Windows and macOS hosts. `zig cc` is actually useful even for cross-compiling Rust projects, because some Rust crates depend on C libraries.

by pornel 5y ago

pjmlp 5y ago

What this kind of stories always miss is that the host platform needs all system libraries for the target platform for anything beyond the basic examples using the standard library. E.g. try to cross compile Metal shading example for iOS from Linux with zig, or do a Win2D UWP rendering application from Linux with zig.

zamadatix 5y ago
I'm not sure what's really "missed", if you call a library other than the stdlib of course you're going to need to provide the appropriate headers/libraries for that as that's got nothing to do with a C compiler.
- pjmlp 5y ago
  In general, it isn't so clear when these kinds of examples are posted. And to go back to my examples, headers and libraries alone won't make it, without the remaining toolchain to create the appropriate package.
  - zamadatix 5y ago
    Well for your particular examples UWP is C++/C#/a few others but it has no direct c binding and iOS APIs are all defined for Objective-C and Swift so sure, you're not going to get far with a C compiler before you even start thinking about a c cross compiler. If you want to cross compile C stuff e.g. a Win32 GUI app with Direct X or get OpenGL bindings for SDL though those all work just fine if you provide the SDK files same as you would compiling natively. The advantage being now you can do all builds from a single build instance just by feeding it the libraries and a target platform.
flohofwoe 5y ago
The Metal shader compiler is an unfortunate special case, because the bytecode and the Metal compiler tools are proprietary and locked up by Apple (there are precompiled binaries of the Metal compiler for Windows, but not Linux). The ball is definitely in Apple's court here, there's nothing any language project can do, except illegally reverse engineering Metal bytecode, which obviously isn't a good idea. The system API problem can be solved by shipping automatically generated API bindings (similar to what Microsoft does with the Rust bindings to the Windows APIs, a similar project for Zig is underway). Once those bindings exist, no Windows SDK is needed anymore and cross-compiling should "just work". PS: Zig actually ships with the mingw headers in the default installation (e.g. windows.h, d3d11.h, dxgi.h etc are all there), I haven't actually tried to cross-compile a Windows executable using the Win32 APIs though, but it looks like it should work already.
- kevin_thibedeau 5y ago
  > illegally reverse engineering Metal bytecode Reverse engineering is legal in the US (unless bound by contract).
- pcwalton 5y ago
  So does every new release of any Windows component require a new version of Zig? That doesn't seem sustainable.
  - flohofwoe 5y ago
    I don't actually know what Windows components mingw supports in detail and how often mingw is updated because of that, but I guess that the important Win32 APIs are stable. I suppose that the new APIs which are highly in flux could be supported by separate packages, like this: https://github.com/marlersoft/zigwin32 https://github.com/marlersoft/zigwin32)
- Cloudef 5y ago
  The metal compiler probably could run with darling
pcwalton 5y ago
Right. Are you going to ship all Windows headers and import libraries to everyone, including DirectX, etc.? Are you going to keep them up to date with every new version of a Windows component? Are you going to ship parts of the macOS, or iOS SDKs? I don't see shipping all targets all the time to be a particularly scalable solution in general. When you start including all libraries necessary to develop actual apps, the download size will eventually get so big that people will complain. Just make it easy for developers to get the targets they need, but don't ship everything by default.
- p0nce 5y ago
  > Just make it easy for developers to get the targets they need, but don't ship everything by default. It seems to be what Flutter is doing, and it must be a ton of work.
- flohofwoe 5y ago
  I'd guess once Zig gets its package manager many target-specific packages can move out of the default installation.
  - pcwalton 5y ago
    Absolutely, which is exactly what I'm arguing for. :)
- slimsag 5y ago
  I'd argue it's less about what the compiler does by default, but rather what it (and the community) enable. For Mach (the Zig game engine I'm working on), I have a Zig build script which fetches the required parts of the macOS and iOS SDKs from GitHub to enable cross compilation from Windows/Linux -> macOS. Zig's linker, zld, enables that to work easily.[0] For SDL.zig, they have also achieved cross compilation for most targets out of the box[1]. Contrast this to say, Go or Rust, where most GLFW and SDL bindings require mucking around with the system dependencies. It doesn't just work out of the box, I think that's really unfortunate and hope other languages work more towards painless installation of C-binding dependencies. [0] https://twitter.com/slimsag/status/1413770578494775298 https://twitter.com/slimsag/status/1413770578494775298 [1] https://github.com/MasterQ32/SDL.zig#support-matrix https://github.com/MasterQ32/SDL.zig#support-matrix

wyldfire 5y ago

> Compared to Zig, cross-compilation in C/C++/Rust seems downright user-hostile: This has been the status quo for so very long. Usually these projects are maintained by different teams. IMO musl is more accessible than glibc and that's part of what makes it easier to distribute. Arm and x86 coexisting for as long as they have is a factor, and so is Kelley's ambition to make this use case well-supported. nostdlib is also well-supported by Zig btw.

vvanders 5y ago

I would not include Rust in that list, in my experience rustup and cargo are miles ahead of C/C++ when cross compiling.

steveklabnik 5y ago
Personally, I see it in three tiers: Rust improved upon those experiences, but I still wish someone would implement what Zig has in rustc.
- vvanders 5y ago
  Yup, fully agreed Zig stands above others here. Cross compiling C/C++ is just a special kind of hell. Each target always has some sort of bespoke toolchain and build environment constraint that add so much unneeded complexity.
- pcwalton 5y ago
  I don't. We could approximate it by shipping all targets by default, but few really want that and the few who do can just install those targets with rustup.
  - nicoburns 5y ago
    Is it really few who want that? Anybody developing server software on windows or mac and deploying on linux could use this. Anybody developing cross-platform client software could use it. I'd guess that a lot of Rust developers currently do development on their target platform, but that's because cross compiling is such a pain. If it were as easy as zig or go then things might well be differen.
    - pcwalton 5y ago
      My x86_64 Rust libraries directory is 86MB. `rustup target list | wc -l` spits out 84 for me. The math doesn't add up.
      - 5y ago

DrBazza 5y ago

It's always a bit harsh comparing a 36 year old language with more-or-less full backwards compatibility, with a new language designed with the benefit of hindsight. That's not to say that it's impossible to do something like that in a C++ compiler but it's going to be more work than there is benefit. Tangentially related: https://twitter.com/__phantomderp/status/1416108650809241601 https://twitter.com/__phantomderp/status/1416108650809241601 C++ also tries to bring in modern programming research when it makes sense, but that also explains why it's like an octopus with extra legs nailed on.

tialaramex 5y ago
The octopus analogy seems especially appropriate. The thing about the legs on an actual octopus is that there's a bunch of local compute substrate in them, if you were to nail extra legs onto the octopus those are rubbish compared to its real legs which can think. For example, move semantics are a peg leg for the octopus. Should an octopus have a peg leg? I'm not a biologist of any sort, but my guess is "No". I can see why C++ wanted to add move (without this performance in some scenarios is just awful) and yet since C++ didn't start out having move semantics and can't give up backward compatibility it has to shoehorn them in with this awkward "hollowed out object" idea. The result is performance still isn't where it could be and the feature is unergonomic.

skohan 5y ago

I don't know much about cross compilation, but in terms of the Rust case, could part of it be the relative complexity of the language compared to Zig?

woogley 5y ago
`zig cc` cross-compiles C, not Zig.
- skohan 5y ago
  No but I mean why the Zig cross compilation story is better than Rust according to this thread
  - woogley 5y ago
    I see. I'll let the real experts add some insight but I don't think language complexity has much to do with it, considering Rust compiles to an IR first anyway. And I would say Rust has a good cross-compilation story as it is. In 2016 (!) I managed to get Rust to compile my SDL2 game to a mipsel device that used a custom GCC toolchain (http://www.gcw-zero.com/develop http://www.gcw-zero.com/develop)
  - steveklabnik 5y ago
    Nothing about 'zig cc' is related to language semantics, it is entirely a toolchain feature. Language semantics do have some bearing on cross compiler difficulty, but IMHO it's not a major factor, especially within the sorts of languages that Rust and Zig are. The largest factor I can think of (compile-time code execution) exists in both Zig and Rust. It's possible I'm forgetting something, though. It doesn't exist in Rust because nobody has proposed it or implemented it, simple as that.
    - sobeston 5y ago
      I think Zig does cross compilation (ignoring for the moment, projects with C dependencies) better because it comes out-of-the-box with the libraries and headers needed to target a lot of systems. In Rust, you typically get additional toolchains via rustup, whereas Zig works on all of the targets with a single install.

zajio1am 5y ago

> cross-compilation in C/C++/Rust seems downright user-hostile: you have to obtain the correct cross-sdk, but it won't tell you which one, or how to get it (some combos don't even exist), or even where to put it. Since advent of multiarch, crosscompilation does not seem harder than regular compilation. Just install package with gcc for target arch and required libraries for target arch (using the same way as gcc and libraries for host arch).

sm_ts 5y ago

I've had to compile only a few times C/++ programs, and the experience can't be really compared to Rust (probably, to any other language :)). Lately I've cross-compiled a few times Linux/Windows programs, and the only thing I had to do (assuming that the underlying crates are compatible, and that the development libraries are in place, which is required for any language) was: rustup target add x86_64-pc-windows-gnu rustup toolchain install stable-x86_64-pc-windows-gnu That's all. Then one can compile with: cargo build --target x86_64-pc-windows-gnu I've also compiled for RISC-V, and it was the same procedure. There are surely issues with individual crates, and possibly with lower-tier targets, but to characterize this procedure as "user-hostile" doesn't make sense.

pornel 5y ago
That's true only for static libraries and pure-Rust projects. For executables and dynamic libraries Rust relies on system-provided linker (except nightly that can enable lld) and target libc already present on the OS (the nice part zig has, but Rust doesn't). Rust totally craps out if you try to make a binary or dylib and you don't already have cross-compilation toolchain on your OS. It's doable from a Linux distro that has cross packages and a GNU target. It's a PITA for anything else, including anything from Windows and macOS hosts. `zig cc` is actually useful even for cross-compiling Rust projects, because some Rust crates depend on C libraries.