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] |
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] |