https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108866
--- Comment #8 from Pali Rohár <pali at kernel dot org> --- Thank you for input, as you already figured out there is lot of work for this. And I think I'm not skilled enough to implement everything properly, so I would have to let this to gcc developers. I will answer questions: > 1) should gcc pass through any arguments to windres? > -I --include-dir=<dir> Include directory when preprocessing rc file > -D --define <sym>[=<val>] Define SYM when preprocessing rc file > -U --undefine <sym> Undefine SYM when preprocessing rc file windres's -I -D and -U are used for when processing "rc" file. So yes, gcc should propagate -I -D and -U to windres for "rc" files (but not to "res" files). > 2) does -m32 or -m64 need handling in any specific ways? This is really a good question and I totally forgot about this. Because gcc's -m32 generates coff for different arch that gcc's -m64, it means that -m32/-m64 switches has to be propagated to windres. I think that gcc's -m32 and -m64 should be "converted" to windres's --target= option (with the correct argument). > 3) the linker has -Wl, for passing arguments to it, does windres need an > equivalent? I think that it is not needed at all because all windres's flags should already have some options in gcc. > 4) windres --help says: > FORMAT is one of rc, res, or coff, and is deduced from the file name > should ".res" be handled too? "rc" is text resource format, "res" is the binary resource format. "coff" is PE/COFF object file format with binary resource. windres has option -J which explicitly sets the input format (and then extension is not used for deduction). So I think that gcc driver should have rules for both text (rc) and binary (res) formats. And in my "test.spec" experiment are rules for both formats. > 5) windres --help has this list of "supported targets": > x86_64-w64-mingw32-windres: supported targets: pe-x86-64 pei-x86-64 > pe-bigobj-x86-64 elf64-x86-64 pe-i386 pei-i386 elf32-i386 elf32-iamcu > elf64-little elf64-big elf32-little elf32-big srec symbolsrec verilog tekhex > binary ihex plugin > > Do they matter? I did not expect to see any "elf" on this list, because > windows obviously doesn't use it. This is for sure bug. ELF does not support embedding windows resource files. Windows resources can be embedded only into PE/COFF image file or into PE/COFF object file. And AFAIK, windres supports parsing both PE/COFF image and object files, but can generate only PE/COFF object file. So windres target list for sure contains non-senses and that is also reason why you got those errors when you specified ELF. > 6) does llvm-windres need to be considered at all? should there be a way to > select it? an -fuse-rc= command option or so? GNU windres is part of the binutils, where is also GNU as. So if the gcc is using GNU as from binutils for assembling then it should use also GNU windres from binutils for processing resources. So in my own opinion, usage of "windres" from gcc should be handled in the same way as usage of "as" from gcc. If gcc has a way to specify its own as binary, then it makes sense to allow specifying its own windres binary. But gcc developers can have different opinion.
