Windows resource files shouldn't be included in the static library
When building a static library, with --default-library static
, the windows resource file gets included in the library, which doesn't make sense.
Practically, when compiling with MSVC for ARM, this breaks building static libraries. Because with MSVC, the resource file is an architecture independent file, and once you're linking it (and in MSVC land, creating a static library is done by the linker as well), it is converted into an arch specific one. By bad luck/coincidence, the resource file is first:
lib /NOLOGO /OUT:src/libdav1d.a src/src_dav1d.rc_dav1d.res 'src/src@@dav1d@sta/picture.c.obj' ...
When processing the input files one at a time, the linker does not yet know what architecture it is operating on:
LINK : warning LNK4068: /MACHINE not specified; defaulting to X86
And then later when it gets to an actual object file, it errors out because it doesn't match the architecture of the previous one:
src\src@@dav1d@sta\picture.c.obj : fatal error LNK1112: module machine type 'ARM' conflicts with target machine type 'x86'
This issue itself could be avoided either by explicitly injecting an /machine:arm
into the command for creating a static library, or by moving the resource file later. But there's no point in including the resource file in the static library at all (I'm not sure if it's just harmless or if it could even end up pulled in when linking the static libdav1d.a into the caller's DLL, where it could mess up the info shown for that DLL).