windres for ELF

[J]

Hello,

Is there a way to use windres to generate an object file that can be
directly linked to an ELF binary?

I use windres in the following way when using mingw to produce .EXEs for
Windows:

windres -J rc -O coff -I[standard Windows headers] -i resource.rc -o
resource.o -F pe-i386|pei-i386|pe-x86-64|pei-x86-64

And this works well, the resultant .o file can be linked along with the
other .o files into an executable.

But would it be possible to do something like

windres -J rc -O coff -I[alternate Windows headers] -i resource.rc -o
resource.o -F ELF-x86-64

Ideally, I'd like to encode a standard-format resource blob, and then use
ELF programming libraries to find the beginning of the resource table, and
then parse it.

For example, I can already take a .RES file, that has been compiled for
little-endian intel format, and link it into an executable, by including it
in an assembler source-file like so:"

---- ASM source file ------------------------------
.global _binary_resource_res
.global _binary_resource_res_size

# The following directive works for most assemblers
.section .rodata

#
.balign 4
_binary_resource_res:
    .incbin "resource.res"
1:
_binary_resource_res_size:
.int 1b - _binary_resource_res

---- end ASM source file --------------------------

Then in the resulting executable, I use the address of the
_binary_resource_res as the beginning of the resource blob, and the second
symbol _binary_resource_res_size as its size to walk the resources.

This works quite well, but I was wondering if there's a way to link the
resource blob directly into the executable, and use the standard ELF tools
(the elfio library, actually) to find the blob and process it.

I've tried every permutation to see what might be possible, and for targets
OTHER than pe-i386|pei-i386|pe-x86-64|pei-x86-64

it errors out, with messages like the following:

x86_64-w64-mingw32-windres: can't get BFD_RELOC_RVA relocation type: bad
value
x86_64-w64-mingw32-windres: can't get BFD_RELOC_RVA relocation type: cause
of error unknown

These two might be handled by passing in some DEFINE value, possibly,
because I suspect the resource-compiler simply doesn't know what binary
format the resource blob should be compiled into. Any insights welcome.

The other types of errors, are these two:

x86_64-w64-mingw32-windres: Can't detect architecture.
x86_64-w64-mingw32-windres: Can't detect target endianness and architecture.

I suspect these might be coming from the post-compilation stage, once the
.rc script has effectively been compiled into a binary .res blob, and that
the final stage for output can't determine what type of .o file this should
be.

Again, any insights or suggestions are welcome, thank you for taking the
time to read and consider the problem

Jean-Claude
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/binutils/attachments/20260823/3fdc22c8/attachment.htm>