Windows System library include issues with build.zig

Hey all, I’ve trying to use zig as a build system for a C base layer that I’ve started and I’m having issues trying to link with the Synchronization.lib to use C11 atomics and my build fails to find the library:
(added to the executable with exe.linkSystemLibrary("Synchronization");)

zig build-exe TemplateApp Debug native-windows: error: error: unable to find Dynamic system library 'Synchronization' using strategy 'paths_first'. searched paths: none

It does look like that, according to the docs, the lib and dll files are named differently which someone in the discord thinks might be part of the problem.

Welcome @Jack,

Call exe.addLibraryPath("./libs") before exe.linkSystemLibrary replacing “./libs” with the path of the directory that contains your library.

1 Like

Its not “my” library, its a windows system library, if i build with clang linking against this is just a case of -lSynchronization, I have no idea where this library exists. If anyone knows where to look for windows libraries i’ll happily give it a try, but i feel like i shouldn’t have to provide the directory for windows libraries, especially as i can link kernel32 and user32 just fine without.

I think this explains what’s going on, particularly this comment:

Only the most commonly used libraries are typically included by default, depending on your choice of build tools. As soon as you use any part of the API that is off the beaten trail, so to speak, you’ll need to explicitly specify the relevant library. Other examples include the process management API and the modern ACL management API. –


That doesn’t explain anything, i’m am linking to it explicitly, zig is just the only build system where I have to be explicit about its path. In both MSVC and Clang all I have to do is be explicit to the linker that I want to link against Synchronization.lib, no additional library paths needed. I don’t believe that it should be required to provide paths for OS libs just because they’re “of the beaten trail” as that comment puts it, and CL and Clang seem to agree with that sentiment.

For now ill just provide the path, but this is an extremely fragile solution as MSVC loves to move its paths around when it updates

This would be great if LazyPath allowed absolute paths :thinking:

They do; const path: std.Build.LazyPath = .{ .cwd_relative = "C:/foo/bar" }

1 Like

Ok, not sure how i missed that docstring :man_facepalming: i think its working now. Thank you