Dynamic Linking does not work on Windows MinGW Target

[AeroSW]

Zig Version

0.13.0

Steps to Reproduce and Observed Behavior

Setup

1. Download raylib release version 5 for MinGW
2. Pull its contents into a directory local with the project, ./raylib
3. Update build target to be MinGW (Windows + GNU = MinGW):

    const target = b.standardTargetOptions(.{
        .default_target = .{
            .os_tag = .windows,
            .cpu_arch = .x86_64,
            .abi = .gnu
        }
    });

4. Ensure you have your dependencies for raylib linked
   • Note the link modes below state static, but the result is the same with dynamic as well.

    exe.linkLibC();
    exe.addIncludePath(b.path("./raylib/include"));
    exe.addLibraryPath(b.path("./raylib/lib"));
    exe.linkSystemLibrary2("uuid", .{
        .preferred_link_mode = .static,
        .needed = true
    });
    exe.linkSystemLibrary2("gdi32", .{
        .preferred_link_mode = .static,
        .needed = true
    });
    exe.linkSystemLibrary2("winmm", .{
        .preferred_link_mode = .static,
        .needed = true
    });

5. Attempt to have build.zig link raylib dynamically

    exe.linkSystemLibrary2("raylib", .{
        .preferred_link_mode = .dynamic,
        .needed = true,
    });

6. Attempt to run zig build --verbose install. It should produce the following error:

error: error(link): DLL import library for -lraylib not found
error: DllImportLibraryNotFound

The attempting to search for the DLL seems to be tied to a raylib.lib file being present despite MinGW configuration using libraylib.a libraries. This might have been an oversight when parsing configurations to search for DLLs.

Expected Behavior

Expected behavior should be for Zig to be able to accurately find the DLL while using MinGW and not MSVC environment.

[dkareh]

Is the problem as simple as Zig looking for raylib.lib and libraylib.dll.a but not libraylibdll.a (as the import library is named in the linked release archive)? Relevant code: https://github.com/ziglang/zig/blob/bb70501060a8bfff/src/link/Coff/lld.zig#L486-L508

Edit: Can you just use exe.addObjectFile(b.path("raylib/lib/libraylibdll.a")) instead of exe.linkSystemLibrary2(...)?

[AeroSW]

There are a few things that are weird about the code you pasted. If Zig is default using GNU, then why is Zig by default using .lib in this code. It seems counter intuitive. .lib extension is related to MSVC compilation, not MinGW. I think adding a branch here makes sense where we also check for lib{s}dll.a should expand it. I'm not sure how often software doesn't use a period to separate the library's name and dll for these static libs.

I see that SDL2 uses a .dll.a in their lib schema. I also see that Vulkan uses .lib when you install it.

Edit: Looking at findLib, it seems the 3rd param is a double array, so we can pass both .dll.a and dll.a as arguments together. This was incorrect, the list of strings is actually the list of library paths. dkareh points this out below.

[AeroSW]

What you recommended works for both raylib.dll and libraylibdll.a. I still find it awkward how the zig source is set up for detecting DLLs using its named methods for linking.

addObjectFile adds the specified LazyPath directly to the compiler command. This however means that you aren't letting the compiler's linker do its job of searching for the library. I would consider this as a work around rather than a solution.

Code Below:

libraylibdll.a

    exe.linkLibC();
    exe.addIncludePath(b.path("./raylib/include"));
    exe.addLibraryPath(b.path("./raylib/lib"));
    exe.linkSystemLibrary2("uuid", .{
        .preferred_link_mode = .dynamic,
        .needed = true
    });
    exe.linkSystemLibrary2("gdi32", .{
        .preferred_link_mode = .dynamic,
        .needed = true
    });
    exe.linkSystemLibrary2("winmm", .{
        .preferred_link_mode = .dynamic,
        .needed = true
    });
    exe.addObjectFile(b.path("raylib/lib/libraylibdll.a"));

raylib.dll

    exe.linkLibC();
    exe.addIncludePath(b.path("./raylib/include"));
    exe.addLibraryPath(b.path("./raylib/lib"));
    exe.linkSystemLibrary2("uuid", .{
        .preferred_link_mode = .dynamic,
        .needed = true
    });
    exe.linkSystemLibrary2("gdi32", .{
        .preferred_link_mode = .dynamic,
        .needed = true
    });
    exe.linkSystemLibrary2("winmm", .{
        .preferred_link_mode = .dynamic,
        .needed = true
    });
    exe.addObjectFile(b.path("raylib/lib/raylib.dll"));

[dkareh]

Agreed, except the third parameter of findLib is the list of library search paths, so it wouldn't work for testing two suffixes. Anyway, adding a check for lib{s}dll.a seems like the most correct change. Hopefully there aren't any other conventions...

You mentioned that my workaround doesn't let the linker search for the library. Maybe we could provide some way to make the linker search for a library without adding any prefixes or suffixes. ld, for example, interprets -l:<filename> as a command to search for a file called exactly <filename>. In fact, I think Zig already supports the colon prefix, but it expects the full path to the library instead of just the basename. But, I can't tell if this is a good idea or not.

[AeroSW]

Yeah, I realized that and forgot to edit my message. Thank you for pointing that out as well! The idea of using ld seems correct, though, without the : in it. It seems the convention specifies :<filename> is an absolute search for the <filename> presented as the argument. With how Zig is currently handling it, I think we are already following the conventions to some extent, but just the number of patterns allowed is restricted.

We should also be allowing searching for DLL files without the .a as well, since the spec says it can support shared libraries for specific operating systems as well. (It mentions .so for ELF and SunOS systems, so the equivalent would be pure .dll for MS)