Hi Guys,
Corinna wrote:
From my POV the linker is the right place to do this, and I think it would
be the right thing to add logic to ld to add the default manifest only for
executables and only if necessary, rather than adding it indiscriminately to
the linker scripts.
Hmm, I suppose that this could be done. If the default manifest is
stored as a binary blob inside the linker then we avoid the problems
associated with cross building and supporting multiple target types.
(Am I correct in thinking that there is only one format for the .rsrc
section ? There is not a 64-bit version or a big-endian version is there ?)
The problems that I foresee are:
1. If the manifest needs to be changed, the linker has to be
changed. Plus we will need to provide a mechanism to convert a
compiled default-manifest.o file into a binary blob that is
then built into the linker.
2. The user cannot examine the contents of the default manifest
without first building an executable and then dumping it.
3. If different manifest versions *are* needed, eg one for Windows 8
and one for Windows 9 maybe, then the linker is going to have to
store multiple binary blobs inside itself and have some way of
selecting the right blob to use.
I suppose that it would work, but I don't like it. Maybe I am just
being too fussy.
GCC could handle the fact to add a default manifest only when building
executables, but it has no idea if a manifest is already present in the
sources or not.
But that does not matter. As long as the gcc provided default manifest
occurs after the user provided default manifest in the list of object
passed to the linker on its command line, the rsrc merging code will
make sure that the user manifest overrides the gcc manifest.
Also, as soon as a new Windows version
with a new GUID comes out, it's much easier and faster to get a binutils
package out than a complete new GCC package.
True. Although you would only need to update libgcc not gcc itself.
I like the gcc-based option because it makes use of features that have
already been implemented (multilib support, spec files to add parameters
to the linker command line), and so in theory the patch to add default
manifest support will be quite small.
Cheers
Nick
_______________________________________________
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
