Static linking crt

Help
1

so on rust, you can static link crt, this is useful especially for windows since there’s a requirement for c dlls that you have to install manually. this isn’t good for my game

with that said, i also wanna keep libc dynamically linked on linux so no issues arise.

i’m also intending on keeping full cross compilation support

2

i understand that this post is probably a question from the fact that it’s in the Help category and describes the edges of a problem statement.

however, there isn’t actually a question here, which might make it more difficult for people to help you. for example, are you asking whether it’s possible to statically link libc (is this the same as crt for you?) in a Zig project? or are you asking for pointers on how to go about setting your build.zig to take advantage of this possibility? have you gotten stuck somewhere along the process?

3

I don’t know what the question is either, but I’ll go ahead and say that static linking the crt on Windows doesn’t work at the moment, because Zig uses MinGW, which only supports dynamic linking. Furthermore, Windows, overall, only supports dynamic linking, because syscalls aren’t stable.
Static linking on Linux is feasible and highly recommended.
So it looks like you got it backwards.

4

I have some great news for you :slight_smile:

  • Rust standard library requires C runtime library (crt) to operate.
    Zig standard library calls the operating system directly without using the C runtime library for both linux and windows. But if you have C dependencies you need to link to the C runtime.
  • Starting with Windows 10 the universal C runtime is shipped with Windows and is updated by the system using windows update. And zig uses the universal C runtime :slight_smile:
1 Like
5

my understanding is that zig can link against MSVC libc! unfortunately i forgot whether there was some obstruction for cross-compiling to link against MSVC that required manual intervention or if there are licensing issues preventing Zig from linking against it out of the box…

6

but is it set to static

[target.x86_64-pc-windows-msvc]
rustflags = ["-C", "target-feature=+crt-static"]
7

see: How to link against static msvc libc on Windows? - #2 by dimdin

2 Likes
8

The question seems to already be answered, but I’m not as familiar with Windows so I went exploring when I saw the initial question.

When I ran

zig build-exe -target x86_64-windows-msvc -lc --show-builtin

I got

// ...
pub const link_mode = std.builtin.LinkMode.static;
// ...

Looking in the compiler source code at src/link/Coff.zig I found:

// ...
const lib_str = switch (comp.config.link_mode) {
    .dynamic => "",
    .static => "lib",
};
// ...
try argv.append(try allocPrint(arena, "{s}vcruntime{s}.lib", .{ lib_str, d_str }));
try argv.append(try allocPrint(arena, "{s}ucrt{s}.lib", .{ lib_str, d_str }));
// ...

So it seems that when link_mode is .static (which is the default for the generic windows-msvc target), Zig is statically linking the crt libraries (as described here).

If you are still concerned, you can take a look at dumpbin.exe /imports your_exe.exe to check the resulting executable. My experiments show the same results for a printf hello world program as when compiling with cl.exe /MT except Zig also links against ntdll.dll

2 Likes
9

AFAIK this is not recommended anymore since around Windows 10 and the ‘Universal C Runtime’ (UCRT), e.g. the UCRT DLL installation is now managed centrally by the Windows Update Process, and not expected to be done by an application (unless you need to support older Windows versions than 10)

I still prefer linking the CRT statically though, it’s just less hassle all around.

10

I just tried it:

main.zig

pub fn main() void {
    _ = std.c.printf("fgsdhjfd\n");
}

const std = @import("std");

build.zig

const std = @import("std");

pub fn build(b: *std.Build) void {
    const target = b.standardTargetOptions(.{});
    const exe_mod = b.createModule(.{
        .root_source_file = b.path("src/main.zig"),
        .target = target,
        .link_libc = true,
        .strip = true,
        .optimize = .ReleaseFast,
    });

    const exe = b.addExecutable(.{
        .name = "fsdfs",
        .root_module = exe_mod,
        .link_libc = true,
        .strip = true,
        .optimize = .ReleaseFast,
        .linkage = .static,
    });
    b.installArtifact(exe);
}

Output:

output
output619×344 30.5 KB

Edit: Ops, sorry. I forgot to set the target to msvc (the default is mingw). With msvc, indeed, it does statically link.

11

is that the master branch? i only use the bleeding edge version

12

are these gnu dlls installed on windows by default or do you need to run the visual c runtime installer?

13

It’s on “Bleeding edge” :grin: (trunk in less dramatic terminology).
These dlls I showed are the normal vcredist. Mingw will link with them.

14

No gnu anything is installed on Windows by default.

15

But as far as I understand, binaries built with _-windows-gnu build and statically link the mingw “gnu” part, and just link against the universal crt. So there is no need to install anything to run the produced binaries (at least since Windows 10).

2 Likes
16

I use xwin and VC-LTL5 in my project. xwin provides an MSVC environment for cross-compiling, and VC-LTL5 can make the exe built on MSVC link only to ucrtbase.dll (which is included with Windows).

2 Likes
17

Just to be clear, the imported DLLs you’re seeing here are system DLLs that are always present, and they’re only there because MinGW-w64 requires them. The MinGW-w64 CRT code is still statically linked into your EXE; there is no run-time dependency on non-Microsoft DLLs.

18

They are not system DLLs (other than Kernel32). They are vcredist, short for visual c runtime redistributable, which is microsoft’s convoluted name for dynamically linked libc. Although they’re from Microsoft, they are not system DLLs because they are not the main interface to Windows (Kernel32 is). In fact, until a short while ago, they were not necessarily present in a Windows installation. The user had to install the infamous vcredist and vcppredist, which would cause a gigantic list of vcredist in the programs list, each one for a slightly different version of it. Since Windows 10, they are now managed as part of windows updates.
Like I mentioned in my edit, compiling with static and targetting msvc gets rid of them (except kernel32), just like compiling with msvc itself with the static flag, which proves they are not necessary.
Mingw did not implement libc for windows, which is why they only offer the dynamically linked version of it.

19

To be clear:

  • I’m only speaking about Windows 10+ here because the Zig standard library doesn’t officially support anything older than that. So from our perspective, we do regard the API set DLLs as system-provided.
  • MinGW-w64 requires those DLLs when used in the “typical” UCRT mode. There is another mode that links directly against ucrtbase.dll instead, but we don’t currently support that because using the API set DLLs is the recommended practice by Microsoft. We probably could relatively easily if there’s demand, though.
  • Either way, when using MinGW-w64 with UCRT, there’s still a ton of CRT code that gets linked into your EXE/DLL statically in the form of mingw32.lib, which is what I was getting at. It’s just not a “pure” static link because it ultimately needs to depend on the system UCRT in some way. But there’s no dynamic dependency on MinGW-specific DLLs or anything like that.
3 Likes