This affects static libc only. If you pass -dynamic -lc then the libc functions are provided by the target system. Some systems only support dynamic libc, such as macOS. I think OpenBSD actually does support static libc though.

https://news.ycombinator.com/reply?id=46864849&goto=item%3Fi...

The very same day I sat at home writing this devlog like a coward, less than five miles away, armed forces who are in my city against the will of our elected officials shot tear gas, unprovoked, at peaceful protestors, including my wife.

https://www.kptv.com/2026/01/31/live-labor-unions-rally-marc...

This isn't some hypothetical political agenda I'm using my platform to push. There's a nonzero chance I go out there next weekend to peacefully protest, and get shot like Alex Pretti.

Needless to say, if I get shot by ICE, it's not good for the Zig project. And they've brought the battle to my doorstep, almost literally.

Abolish ICE.

I too am sick of internal compiler errors

I don’t mind someone doing politics stuffs. Heck I am in for privacy and no enterprise model of software. Big Stallman fan here.

But I would really suggest keeping politics out of Zig stuffs.

I don’t even know what ICE is. Just read about it.

This is a show of power.

Like: “I am an American and since I am building the software, I am going to push MY politics into your throat”.

That means, to show similar power, I need to build a software as influential as Zig so that I can push my agendas of my country down your throats.

Heck let me do just that.

Keep politics to politics forums, keep code to code.

I too am sick of internal combustion engines, a product of the last century.

I too am sick of intrusion countermeasures electronics. Think of all the poor netrunners out there.

Yes but we already have to do that for our own standard library. For shared codepaths (e.g. math) it's strictly fewer potential bugs.

This use case is unchanged.

If you specify -target x86_64-windows-gnu -lc then some libc functions are provided by Zig, some are provided by vendored mingw-w64 C files, and you don't need mingw-w64 installed separately; Zig provides everything.

You can still pass --libc libc.txt to link against an externally provided libc, such as a separate mingw-w64 installation you have lying around, or even your own libc installation if you want to mess around with that.

Both situations unchanged.

Seems like it ought to be able to do inlining and dead code stripping which, I think, wouldn't be viable at link time against optimized static libraries.

There's solid reason for the translation here; the Zig core team is aiming to eliminate duplicated code and C functions, and avoid the need to track libc from multiple sources. In the future, LLMs could serve as part of this, but they are currently quite terrible at Zig (as far as I understand it, it's not a lack of Zig code samples, it's an imbalance of OLD Zig to NEW Zig, as Zig changes quite frequently).

You would need to consider if it is even worth it translating your C code. If the paradigm is identical and the entire purpose would be "haha it is now one language," surely you could just compile and link the C code with libzigc... In my opinion, it's not worth translating code if the benefit of "hey look one language" requires the cost of "let's pray the LLM didn't hallucinate or make a mistake while translating the code."

hallucinations in a libc implementation would be especially bad

Have you ever used an LLM with Zig? It will generate syntactically invalid code. Zig breaks so often and LLMs have such an eternally old knowledge cutoff that they only know old ass broken versions.

The same goes for TLA+ and all the other obscure things people think would be great to use with LLMs, and they would, if there was as much training data as there was for JavaScript and Python.