Zig cc: A drop-in replacement for GCC/Clang (2020) • Hacker News Board

Re: Zig cc: A drop-in replacement for GCC/Clang (2020)

#51

Post by sm_ts » Sun, Jul 18, 2021, 4:58 PM UTC

pornel wrote: post #6

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…

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.

Re: Zig cc: A drop-in replacement for GCC/Clang (2020)

#52

Post by skeetmtp » Sun, Jul 18, 2021, 5:04 PM UTC

jedisct1 wrote: post #47

jcalvinowens wrote: post #37

Earlier quoted context omitted.

Have you tried ASAN? If you like valgrind, you will be in love with ASAN, it's really surpassed it at this point IMHO.

Be careful with ASAN on cryptographic code, though. It can introduce side channels.

ASAN is not meant to be used in production though. Or I missed something in your comment.

Re: Zig cc: A drop-in replacement for GCC/Clang (2020)

#53

Post by manish_gill » Sun, Jul 18, 2021, 5:07 PM UTC

I literally started learning Zig today after watching a talk on youtube by Andrew Kelly. The drop-in C compiler replacement lured me.

But what surprised me immediately and the thing I'm absolutely loving is the error handling (https://twitter.com/mgill25/status/1416720958988210177) and the comptime features.

I've done Rust and while I love what it's doing, getting into low-level C-world without the overhead of a language like Rust feels liberating.

Re: Zig cc: A drop-in replacement for GCC/Clang (2020)

#54

Post by vlovich123 » Sun, Jul 18, 2021, 5:13 PM UTC

Can it be used for c++ code? Also we build LLVM tip of tree from scratch. Is it easy to get the version of zig cc built against the newer version or does one have to wait for the project authors to update to the latest (I’m assuming my it’s a non-trivial amount of work?)

Re: Zig cc: A drop-in replacement for GCC/Clang (2020)

#55

Post by adamdusty » Sun, Jul 18, 2021, 5:13 PM UTC

msingle wrote: post #39

bionade24 wrote: post #34

Earlier quoted context omitted.

zig cc uses LLVM under the hood.

right now - my understanding is once the self-hosted compiler is done, LLVM will be optional.

I think LLVM will still be required for release builds.

Re: Zig cc: A drop-in replacement for GCC/Clang (2020)

#56

Post by zamadatix » Sun, Jul 18, 2021, 5:15 PM UTC

pjmlp wrote: post #48

zamadatix wrote: post #38

Earlier quoted context omitted.

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.

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.

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.

Re: Zig cc: A drop-in replacement for GCC/Clang (2020)

#57

Post by sobeston » Sun, Jul 18, 2021, 5:18 PM UTC

steveklabnik wrote: post #46

skohan wrote: post #25

Earlier quoted context omitted.

No but I mean why the Zig cross compilation story is better than Rust according to this thread

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 i…

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.

Re: Zig cc: A drop-in replacement for GCC/Clang (2020)

#58

Post by steveklabnik » Sun, Jul 18, 2021, 5:21 PM UTC

sobeston wrote: post #57

steveklabnik wrote: post #46

Earlier quoted context omitted.

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 i…

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.

Absolutely, hence a toolchain thing.

Re: Zig cc: A drop-in replacement for GCC/Clang (2020)

#59

Post by flohofwoe » Sun, Jul 18, 2021, 5:49 PM UTC

What's usually not mentioned is that zig cc is also an ObjC/ObjC++ compiler, which is important on macOS to talk to system framework APIs. Zig 0.8.0 still has some warts on macOS (for instance one needs to tell Zig to use the Apple system linker), but those will be fixed in 0.9.0 (AFAIK it already works in the main branch).

Re: Zig cc: A drop-in replacement for GCC/Clang (2020)

#60

Post by flohofwoe » Sun, Jul 18, 2021, 5:54 PM UTC

pjmlp wrote: post #8

pornel wrote: post #6

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…

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.

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.