Re: Cygport and auto-manifestize compatibility manifest

[Corinna Vinschen <corinna-cygwin at cygwin dot com>]

On Nov 20 17:06, Corinna Vinschen wrote:
> On Nov 20 10:43, Christopher Faylor wrote:
> > On Wed, Nov 20, 2013 at 04:01:01PM +0100, Corinna Vinschen wrote:
> > >On Nov 20 09:47, Charles Wilson wrote:
> > >> On 11/20/2013 8:28 AM, Corinna Vinschen wrote:
> > >> >Apart from the fact that it would be nice if our linker would do this
> > >> >automatically and transparently,
> > >> 
> > >> Or libtool, if you use it to link your exe?  PTC...since
> > >> $new-libtool is pretty high on my to-do list.
> > >> 
> > >> It'd be better if there was an option to ld/gcc, of course -- but
> > >> the details would be rather complicated.  You wouldn't want to
> > >> invoke a separate executable like windres b/c then your build
> > >> recipe/makefile would have to change.  Best if $LD_FLAGS could be
> > >> used... maybe something hideously ugly like -w32-manifest-compat
> > >> <file> [1] where <file> is not a full XML manifest, but rather
> > >> contains a list of GUIDs [2], and ld/gcc autogenerates the manifest
> > >> with just that stuff.
> > >> 
> > >> That way, if you manually create a manifest (for other purposes),
> > >> you could just /not/ use the new flag.
> > >
> > >The other way around.  If your project does not link in a resource
> > >anyway, which means that your project is WIn32 aware, then ld should
> > >add the manifest resource by default.  Everything else means that
> > >you have to tweak all project configury, which is only barely descibed
> > >by a can of worms...
> > >
> > >A simple windres call in cygport would be nice, but unfortunately windres
> > >does not yet have this capability to add a resource to an existing exe.
> > >
> > >> I know, SHTDI...
> > >
> > >Yes, that's pretty much the problem.  Even my ugly workaround is bad,
> > >because it only works on Windows.  No more cross-building on Linux :-P
> > 
> > Some more ugly hacks: Could cygwin itself create the manifests when it
> > runs a program iff they don't exist?  Or, alternately, setup.exe?  Or
> > rebase?
> 
> Cygwin itself, never I guess.  See my other mail I just sent.
> As I said, *extremly* sensitive.  Rinse and repeat.
> 
> Setup could do it, but the problem is the existence of sections with
> long section names, especially debug sections and the .gnu_debuglink
> section.  It's quite the mess and rather complicated to perform since
> you need to be sure to filter out the problematic sections, or better,
> to perform the action *after* strip, and *before* adding the
> .gnu_debuginfo section.

For the records, here's the most dumb workaround:

  #!/bin/bash
  #
  # Assumes that a default manifest has been stored in /etc/defaults
  #
  cd /bin
  for i in *.exe
  do
    if [ ! -f "${i}.manifest" ]
    then
      cp /etc/defaults/default.manifest "${i}.manifest"
      # Enforce updating Activation Context Cache
      touch "${i}"
    fi
  done

This works, but it's pretty ugly.  1000 exe files, 1000 manifest files.
Hardlinks work, but are restricted to 1024 per file.  And it doesn't
actually make the output of ls /bin better.  Still, if we don't find a
better solution, this might be the way to go.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

Attachment: pgp2tg0bB_R1e.pgp
Description: PGP signature