Open noxabellus opened 3 months ago
Attempting to reproduce this, but I'm getting completely different results/errors.
This command is a bit strange:
zig build-exe repro.zig -Dtarget=x86_64-windows-msvc
-Dtarget=x86_64-windows-msvc
is a build system-specific option. The build-exe
equivalent is -target
Changing to -target
and adding -lc
gives me:
> zig build-exe repro.zig -target x86_64-windows-msvc -lc
error: lld-link: undefined symbol: getpid
note: referenced by C:\Users\Ryan\Programming\Zig\tmp\repro.zig:6
note: repro.exe.obj:(repro.main)
To fix that, I have to add -loldnames
For the --libc
part:
> zig libc > x86_64.libc
> zig build-exe repro.zig -target x86_64-windows-msvc -lc -loldnames --libc x86_64.libc
error: unable to find dynamic system library 'oldnames' using strategy 'paths_first'. searched paths: none
Without oldnames
I'm back to the getpid
linker error:
> zig build-exe repro.zig -target x86_64-windows-msvc -lc --libc x86_64.libc
error: lld-link: undefined symbol: getpid
note: referenced by C:\Users\Ryan\Programming\Zig\tmp\repro.zig:8
note: repro.exe.obj:(repro.main)
-Dtarget=x86_64-windows-msvc
is a build system-specific option. Thebuild-exe
equivalent is-target
What the heck is happening when I run with that flag, then? Is it still doing a gnu build?
- This isn't linking libc
This one is just a copy/paste problem, I did in fact pass -lc
, but when I was copying out my inputs to make the issue I missed that bit.
After changing -Dtarget=x86_64-windows-msvc
to -target x85_64-windows-msvc
I needed to add oldnames
as well, which compiles; but then adding the libc parameter I get the same unable to find dynamic system library 'oldnames'
and without -loldnames
I'm back to 'process.h' file not found
(Edit: Apologies for accidentally closing the issue, noob mistake. I've reopened it now.)
What the heck is happening when I run with that flag, then?
Excerpt from zig build-exe --help
:
-D[macro]=[value] Define C [macro] to [value] (1 if [value] omitted)
Is it still doing a gnu build?
Yes, Zig defaults to MinGW for Windows.
I bypassed the header issue by just manually adding the symbols I needed in my zig code, now it's saying that the libs are all missing. And again, if I go to the provided directory and Get-Item
the files it says are missing, they in fact are not
Zig Version
0.13.0
Steps to Reproduce
I first noticed this issue while trying to cross compile my project which depends on bdwgc, from a windows 11 x86_64 vm for an aarch64-windows-msvc target. Strangely, I am able to compile the bdwgc module I've created directly, but trying to build it as a dependency from my own module's build script causes errors: either I get a series of errors saying the libc libs are x64 and I need aarch ones; or when I supply a libc file pointing to the correct binaries, an error saying that
process.h
cannot be found.Why the former error is happening, I haven't been able to nail down. As I said, I do have the binaries and if I run the cross targeted build in bdwgc's directory it works fine. The second issue seems more definitely a compiler issue, though, so I decided to try and track that first.
I have produced a minimal reproduction here that recreates the missing header issue with no cross compilation or external libraries (other than libc, of course).
I can compile the following code with
zig build-exe repro.zig -Dtarget=x86_64-windows-msvc
However, if I run
zig libc
, I get the following output:Saving this to
x86_64.libc
and running the command again, supplying this libc file like sozig build-exe repro.zig -Dtarget=x86_64-windows-msvc -lc --libc x86_64.libc
Produces this error:
If I run
Get-Item "C:\Program Files (x86)\Windows Kits\10\Include\10.0.22621.0\ucrt\process.h" | Format-List
, I can confirm the file does exist in the directory supplied in the libc file:Observed Behavior
Passing a generated libc file directly into a libc compiler option produces errors.
Expected Behavior
Passing a generated libc file directly into a libc compiler option works the same as no libc compiler option