This is the mail archive of the cygwin-apps mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Cygport and auto-manifestize compatibility manifest


On Nov 20 16:01, 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

I added the sources for my now radically simplified test to this mail.
It consists of three files:

  add-cygwin-default-manifest.c:  The source code adding the manifest.
  cygwin-default-mainfest.rc:     The default resource containing the
                                  manifest.  It's target-agnostic.
  Makefile:                       The Makefile.

To build the executable, just run `make'.  This creates the
add-cygwin-default-manifest executable with the embedded manifest.

To add a manifest to binary "foo.exe", run `make doit EXE=foo.exe'
add-cygwin-default-manifest.exe pulls its own manifest and copies it
over to foo.exe.  This is the step which I didn't manage to reproduce
via objcopy.

Note the crude way how `make doit' works.  The UpdateResource
functionality is *extremly* sensitive against having an open handle to
the file still open in the same binary somewhere.  If you try something
like this:

  doit:
  	strip $(EXE)
	objcopy --remove-section=.gnu_debuglink $(EXE)
	./add-cygwin-default-manifest $(EXE)

then you'll get an error message "EndUpdateResource: Win32 error 5".
Apparently, `make' has an open handle to $(EXE) and this is propagated
somehow to the child processes.  As a side note, trying to call, say,
GetBinaryType before calling BeginUpdateResource, or even stuff like
CreateFile/CloseHandle(!!!) will end up with "EndUpdateResource: Win32
error 5".  As I wrote, *extremly* sensitive.  That sounds much better 
than "badly written"...


Corinna

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

Attachment: add-cygwin-default-manifest.c
Description: Text document

Attachment: cygwin-default-manifest.rc
Description: Text document

Attachment: Makefile
Description: Text document

Attachment: pgpSmppaRpwR5.pgp
Description: PGP signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]