From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 407F63857839; Fri, 15 Mar 2024 17:27:17 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 407F63857839 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1710523637; bh=biqKZAChMT3E2YR2AkjVYlttBonkfRAussrB+6Ob5A0=; h=From:To:Subject:Date:In-Reply-To:References:From; b=nU9+QJLKbCt/RJxkxs/VLsceTWkGSXUoRCF2rxiWGVzjdUx2HSZjr1/P3HHUJn97y iLE3Zrtc/V3FTfIQW7GCdC5IbNQpF1jo1ukJY0Wjqwx5fu/KaqNpG3faUgxCqB7Qux yTdeZL0B5AxcQ64y8+iwdvifq8VaNNQePqCNFRYQ= From: "pali at kernel dot org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/108866] Allow to pass Windows resource file (.rc) as input to gcc Date: Fri, 15 Mar 2024 17:27:16 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 12.2.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: pali at kernel dot org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D108866 --- Comment #8 from Pali Roh=C3=A1r --- Thank you for input, as you already figured out there is lot of work for th= is. And I think I'm not skilled enough to implement everything properly, so I w= ould have to let this to gcc developers. I will answer questions: > 1) should gcc pass through any arguments to windres? > -I --include-dir=3D Include directory when preprocessing rc f= ile > -D --define [=3D] Define SYM when preprocessing rc file > -U --undefine 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=3D 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 alr= eady 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-bi= gobj-x86-64 elf64-x86-64 pe-i386 pei-i386 elf32-i386 elf32-iamcu elf64-litt= le elf64-big elf32-little elf32-big srec symbolsrec verilog tekhex binary i= hex plugin >=20 > Do they matter? I did not expect to see any "elf" on this list, because w= indows 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/C= OFF 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=3D 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 windr= es 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 binar= y, then it makes sense to allow specifying its own windres binary. But gcc developers can have different opinion.=