Unable to link a static library with MSVC for ARM, when windows resources are included

[mstorsjo]

When creating a library that contains a windows resource (to add metadata about the library), e.g. like this, building with MSVC can fail when targeting non-x86 architectures.

mylib_rc_obj = winmod.compile_resources(rc_file)
mylib = library('mylib', mylib_rc_obj, ...)

With MSVC tools, the output of rc.exe is an arch independent resource file (contrary to windres which by default outputs an arch specific object file). When including this in a static library, MSVC lib.exe will convert it into an arch specific object file. (Including it in static libraries is of course pointless, but since one doesn't know if the library is going to be static or shared, it gets included in both.)

lib.exe will infer what architecture to use, based on earlier object files processed, or based on the /machine: option. Normally the /machine: option isn't needed and thus Meson doesn't currently pass it.

However, if the resource file gets passed to lib.exe before any of the actual object files, creating the library will fail:

$ lib /NOLOGO /OUT:libmylib.a src/src_mylib.rc_mylib.res 'src/src@@mylib@sta/implementation1.c.obj' ...
LINK : warning LNK4068: /MACHINE not specified; defaulting to X86
src\src@@mylib@sta\implementation1.c.obj : fatal error LNK1112: module machine type 'ARM' conflicts with target machine type 'x86'

If the lib.exe invocation would include a /machine: parameter, this wouldn't be an issue. Being able to omit the resource file from the static library altogether (close to what is discussed in #4159) would also solve the situation, as including the resource file in the static library is mostly pointless, at least when the resource is just DLL metadata.

[nirbheek]

Sounds like we should detect this automatically and ignore the compiled resource file when generating a static library.

[mstorsjo]

Hmm, I'm a little torn about that kind of fix. On one hand, it's sounds straightforward and probably right in most concievable cases. On the other hand, I'm wondering if there are legitimate cases of resources in static libraries - e.g. like if the library runs a GUI defined in the resource. But linking that would probably need -Wl,---wholearchive to actually pull in the resources. Not sure if anybody actually does anything like that.

[jon-turney]

I think adding the correct /machine: parameter would be straightforward after #4451, since we'd have access to the target architecture.

See also #4040

[jon-turney]

Actually, I think #4040 is slightly different, as that's about linking a shared library, not a static one, but problem and solution seem to be the same. Anyhow, attempted to fix this with #4724.