This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: Cygport and auto-manifestize compatibility manifest
- From: Christopher Faylor <cgf-use-the-mailinglist-please at cygwin dot com>
- To: cygwin-apps at cygwin dot com
- Date: Thu, 21 Nov 2013 09:27:08 -0500
- Subject: Re: Cygport and auto-manifestize compatibility manifest
- Authentication-results: sourceware.org; auth=none
- References: <20131120132853 dot GN2936 at calimero dot vinschen dot de> <528CCB69 dot 4030804 at cwilson dot fastmail dot fm> <20131120150101 dot GQ2936 at calimero dot vinschen dot de> <20131120154327 dot GA3501 at ednor dot casa dot cgf dot cx> <20131120160637 dot GT2936 at calimero dot vinschen dot de> <528DE757 dot 7080304 at lysator dot liu dot se> <20131121114823 dot GC2936 at calimero dot vinschen dot de>
- Reply-to: cygwin-apps at cygwin dot com
On Thu, Nov 21, 2013 at 12:48:23PM +0100, Corinna Vinschen wrote:
>On Nov 21 11:58, Peter Rosin wrote:
>> On 2013-11-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:
>> >>>> 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.
>>
>> One snag with having setup do it, is that package maintainers running
>> 'make check' will not test what is actually deployed (unless jumping
>> through hoops).
>>
>> The behavior of the exes did change with the manifest after all, which
>> was the whole point with all this manifest crap, right?
>
>Absolutely.
>
>But tweaking the existing executables is just some desperate short-term
>method. What we really need is a linker which adds a default manifest
>if the project does not provide its own.
>
>I talked to collegues, and we're going to work on a patch to ld at some
>point not too far in the distance. For the time being, we created a
>workaround for ld using just a an additional cygwin-default-manifest.o
>file in /usr/$(target)/lib, and a linker script tweak:
>
>@@ -143,7 +143,8 @@ SECTIONS
> }
> .rsrc BLOCK(__section_alignment__) :
> {
>- *(.rsrc)
>+ *(EXCLUDE_FILE (cygwin-default-manifest.o) .rsrc)
>+ KEEP (cygwin-default-manifest.o(.rsrc))
> *(SORT(.rsrc$*))
> }
> .reloc BLOCK(__section_alignment__) :
Shouldn't the KEEP line be after the SORT line?
If you send me a patch, I'll release new versions of binutils.
cgf