Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

windres from WinLibs GCC 14.1.0 r2 fails when trying to compile a resource file #222

Closed
luisdallos opened this issue Jun 11, 2024 · 5 comments

Comments

@luisdallos
Copy link

luisdallos commented Jun 11, 2024

When I try to compile a resource file with windres utility from current WinLibs GCC 14.1.0 release (r2), the following error shows up:

windres -i test.rc -o test.o --include-dir=.
windres: bfd_set_arch_mach(aarch64): cause of error unknown

Looks like that binutils is being built with support for some extra targets as shown in windres help screen (windres --help | grep -F "supported").

  • 32-bit windres:

    • Current output:

      windres.exe: supported targets: pe-i386 pe-bigobj-i386 pei-i386 elf32-i386 elf32-iamcu pdb elf32-little elf32-big pe-x86-64 pei-x86-64 pe-bigobj-x86-64 elf64-x86-64 elf64-little elf64-big pe-aarch64-little pei-aarch64-little elf64-littleaarch64 elf64-bigaarch64 elf32-littleaarch64 elf32-bigaarch64 elf32-littlearm elf32-bigarm srec symbolsrec verilog tekhex binary ihex plugin

    • Expected output (windres from WinLibs GCC 14.1.0 r1):

      windres.exe: supported targets: pe-i386 pe-bigobj-i386 pei-i386 elf32-i386 elf32-iamcu pdb elf32-little elf32-big srec symbolsrec verilog tekhex binary ihex plugin

  • 64-bit windres:

    • Current output:

      windres.exe: supported targets: pe-x86-64 pei-x86-64 pe-bigobj-x86-64 elf64-x86-64 pe-i386 pei-i386 elf32-i386 elf32-iamcu pdb elf64-little elf64-big elf32-little elf32-big pe-bigobj-i386 pe-aarch64-little pei-aarch64-little elf64-littleaarch64 elf64-bigaarch64 elf32-littleaarch64 elf32-bigaarch64 elf32-littlearm elf32-bigarm srec symbolsrec verilog tekhex binary ihex plugin

    • Expected output (windres from WinLibs GCC 14.1.0 r1):

      windres.exe: supported targets: pe-x86-64 pei-x86-64 pe-bigobj-x86-64 elf64-x86-64 pe-i386 pei-i386 elf32-i386 elf32-iamcu pdb elf64-little elf64-big elf32-little elf32-big srec symbolsrec verilog tekhex binary ihex plugin

Also, in $MSYSTEM_PREFIX/$MSYSTEM_CHOST/lib/ldscripts/ folder there are some extra LD scripts, namely aarch64pe*.x*, arm64pe*.x* and i386pep*.x* (the latter set being expected in x86_64 binutils though).

This issue may be related with changes recently introduced in binutils.winlib recipe at commit 4df9c70

@luisdallos
Copy link
Author

UPDATE: Issue already reported at #221.

@luisdallos luisdallos reopened this Jun 11, 2024
@luisdallos luisdallos closed this as not planned Won't fix, can't repro, duplicate, stale Jun 11, 2024
@brechtsanders
Copy link
Owner

I am hoping and somewhat preparing to include Windows on ARM (aarch64) as soon as it becomes available. Hopefully GCC 15 will be the release where it is finally supported.

I can reproduce the errors (only with the 64-bit target though).

But what I don't understand is why adding the extra target support to binutils breaks it.

Did I miss some configuration parameter to make it default to the desired platform architecture?

@sisyphus
Copy link

But what I don't understand is why adding the extra target support to binutils breaks it.

Yes - that seems odd.
Assuming that "pe-x86-64" is the correct target (because it's the one mentioned first in windres --help), I had tried inserting --target=pe-x86-64 into the windres command, but the same error still occurred.

Is there some way I should be able enforce the default ?

@brechtsanders
Copy link
Owner

No idea. This looks broken. I have switched back to building binutils for one specific target only, and updated the latest the files for the latest 2 releases.

@sisyphus
Copy link

I have switched back to building binutils for one specific target only, and updated the latest the files for the latest 2 releases.

Thank you !!
This fixes my (closed) issue over at #221

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants