Re: [Bug ld/16790] [cygwin|mingw] ld -v creates a.exe

[Nicholas Clifton]

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