Re: Repost: [PATCH] [cygwin|mingw] Create UAC manifest files.

[Charles Wilson]

Ralf Wildenhues wrote:
> * Charles Wilson wrote on Sun, Feb 21, 2010 at 10:09:43PM CET:
>> Ralf Wildenhues wrote:
>>> If the
>>> latter, then I don't see how the manifest file ever gets to be installed
>>> at `make install' time, nor uninstalled at `make uninstall' time?
>> It was a deliberate choice -- a shortcut -- to NOT install the manifest.
> 
> So the uninstalled stuff works but the installed stuff won't.  Ouch.
> 
>>  The RTTD for packages which are intended to build executables with
>> "bad" names is to handle the manifest stuff themselves.
> 
> RTTD?  Real-Time Track Data?

Right Thing To Do.

>> This implementation is intended as a convenience so that the /build/
>> doesn't die for hard-to-explain reasons, on Vista and above.
> 
> You'd rather have the build succeed but the installed stuff be broken?
> Why that?  

Because there are so many variables in what can/should go into the
.manifest; we really have no way of anticipating all of the decisions
the developer needs to make when they handcraft a .manifest file. We
CAN, however, autogenerate a manifest file with the barest minimum of
contents, so that the executable will at least RUN in a normal
build/test cycle.

> Why do we go to lengths making uninstalled testing work when
> it doesn't reflect a best effort that the installed thing will also
> work?

Frankly, to highlight to the developer EXACTLY what they need to do. Our
 autogenerated .manifest MAY be suitable for end-user deployment, but it
might not.  By making it clear that there's nothing wrong with the
developer's code, only the installation, the developer can then choose
to copy "our" .manifest and add it to their source AND add explicit
rules to install it (or write their own from scratch).

The downside of all of this is that you need special rules, once again,
in your Makefile.am on win32, which means modifications to configure.ac
as well to create an IS_WIN32 AM_CONDITIONAL.  Yuck.

>> I'm ignoring entirely the compiled-in .manifest resource issue.  That's
>> just too ugly for words (below).
> 
> Not sure what you mean here, but if a user provides a .rc resource that
> it compiled in that doesn't seem ugly to me at all.  We do this for one
> of our w32 programs, and it's really straightforward.  No bad name
> though.

Well, you need the aforementioned AM_CONDITIONAL, plus automake doesn't
have any rules for .rc -> .o.  I had to add this to xzutils' Makefile.am:

if COND_W32
xz_SOURCES += xz_w32res.rc
endif

# Windows resource compiler support
ltrc_verbose = $(ltrc_verbose_$(V))
ltrc_verbose_ = $(ltrc_verbose_$(AM_DEFAULT_VERBOSITY))
ltrc_verbose_0 = @echo "  CCRC  " $@;

.rc.o:
        $(ltrc_verbose)$(RC) $(DEFS) $(DEFAULT_INCLUDES) \
                $(INCLUDES) $(xz_CPPFLAGS) $(CPPFLAGS) $(RCFLAGS) \
                -i $< -o $@

and configure.ac:

# We do some special things on Windows (32-bit or 64-bit) builds.
case $host_os in
        mingw* | cygwin*) is_w32=yes ;;
        *)                is_w32=no ;;
esac
AM_CONDITIONAL([COND_W32], [test "$is_w32" = yes])

... standard LT_INIT([win32-dll]) ...
LT_LANG([Windows Resource])


It might be a LITTLE cleaner if automake had built-in rules for .rc->.o,
but not much.  It really doesn't look like something we can coerce
automatically.

So...given those limitations, Yaakov & I thought it would be more
acceptable to propose a smaller, limited purpose patch that did NOT get
into all those weeds.

>> Now, this interacts with an issue below, but I'll hint at it here: even
>> if the source provides an explicit manifest file, it's over in the
>> ${srcdir}, and not necessarily in the ${builddir}.
> 
> That is the developer's problem, not ours.  Either she has a rule to
> create the manifest by make, or to copy it over, or the installation
> instructions forbid VPATH builds.  Any way, we don't care.  We don't
> have to care about obvious developer bugs.

So the developer is supposed to copy their actual.exe.manifest over to
${builddir}/.libs/, so that the actual manifest (as oppposed to our
autogenerated one) is used by the actual program, but our autogenerated
one is used by the wrapper?  But if --static, then they should copy it
over to ${builddir} and we should do nothing?

It is neither our fault nor the developers' that Vista+ is so @#^!# screwy.

>>> 1) --mode=clean removes .manifest files even if --mode=link did not
>>> create them, namely when the name of the program does not match
>>> *instal*|*patch*|*setup*|*update*.
>> Hmm.  How about if the generated manifest file includes a comment, that
>> specifies it was automatically generated by libtool, and then
>> --mode=clean only removes it from the ${builddir} if the file (a)
>> exists, and (b) contains that comment?
> 
> Yes, that sounds reasonable.

OK.

>> (It would add .libs/*.manifest
>> to $rmfiles only after an explicit existence check, but no corresponding
>> 'have libtool comment' check...)
> 
> You can just unconditionally remove the file below .libs on Cygwin, I
> don't care.  .libs is libtool's domain.

OK.

>> And, we only create a ${builddir}/[.libs/]foo.exe.manifest if there
>> isn't one in ${srcdir}.  If there IS, then we just copy it over to both
>> ${builddir}/ and ${builddir}/.libs/.
> 
> No.  There is no reason to copy over a manifest from srcdir.  That makes
> no sense.

See above.

>> For executables with "good" names, we never generate a .manifest, but if
>> ${builddir}!=${srcdir} AND there is a .manifest in ${srcdir}, then we
>> copy it over to both ${builddir}/ and ${builddir}/.libs.
> 
> Again, I don't see that as necessary.

See above.

>>> Neither this nor manifest creation
>>> and usage, nor (0) are covered in the libtool testsuite.  But need to

>>> So Automake needs to be
>>> fixed.
>> Well, switching to libtool --mode=clean is a big change, even if only
>> for the libtool-clean: rule.  Maybe a less disruptive change to progs.am:
>>
>> untested pseudocode addition:
>>
>>  ?LIBTOOL?       test -n "$(EXEEXT)" || exit 0; \
>>  ?LIBTOOL?       list=`for p in $$list; do echo "$$p"; done | ...
>>  ?LIBTOOL?       echo " rm -f" $$list; \
>>  ?LIBTOOL?       rm -f $$list
>> +?LIBTOOL?  for p in $$list; do
>> +?LIBTOOL?    if [ -e ${p}${EXEEXT}.manifest -a \
>> +?LIBTOOL?      grep "magic" ${p}${EXEEXT}.manifest >/dev/null 2>&1 ];
>> +?LIBTOOL?    then
>> +?LIBTOOL?      rm -f ${p}${EXEEXT}.manifest
>> +?LIBTOOL?    fi
>> +?LIBTOOL?  done
> 
> That's even more ugly in my eyes.

It may be ugly, but since we do not KNOW if libtool --mode=clean
actually works when used in this context, on all platforms in all
situations. So making THAT change turns this relatively minor patch,
which ostensibly affects only win32, into a major behavioral
modification for all platforms.  With all the delays and requisite
testing that requires.

The ugly change above has far fewer potential ramifications.

> As I said, I'm willing to live with a need for newer Automake for a
> clean solution; in the meantime, users might need to workaround with
>   clean-local:
>         rm -f foo.manifest

Well, OK...

>>> 4) How many code instances does this patch help *in practice*?  I
>>> suppose you guys know since you've used this for a lot of packages,
>>> but couldn't find data in the cited email threads.  I'd like to gauge
>>> the importance of this being fixed in libtool against the regressions
>>> this patch may cause, and the cost of waiting (or not waiting) for an
>>> Automake fix to propagate.
>> The following packages, on my cygwin installation, include .manifest
>> files for certain exe's:
>>
>> coreutils (install)
>> texinfo (install-info)
>> patch
> 
> These three don't use libtool.
> 
>> gtk2 (gtk-update-icon-cache)
>> shared-mime-info (update-mime-database)
> 
> Do these use program executables get linked with libtool?
> 
>> I'm sure there are others which I don't personally have installed.  And
>> some of these may utilize their own methods, rather than libtool, of
>> creating manifest files *for installation*.  I'm pretty sure none of
>> them do anything manually to allow the uninstalled .exe's to operate
>> (such as manually creating a .libs/*.manifest file).
> 
> I've yet to see a definite case where this patch is needed at all in
> practice.

Well, Yaakov maintains almost 1500 packages as part of the cygwin ports
project, and he's the one that original proposed this patch.  I'll ask
him to chime in here.

It really sounds to me as if you would prefer that developers of
packages that create executables with "bad" names:

1) MUST provide a .manifest file
2) MUST manually add sufficient rules to copy that .manifest to
${builddir}/ and manually add correct clean: rules to get rid of that copy
3) MUST manually add sufficient rules to install said manifest file
4) libtool should only be concerned with getting a manifest into /.libs.
And really, if the project is responsible for creating one, and getting
it into ${builddir}, then libtool doesn't need to autogenerate one, it
can simply copy it into .libs if necessary
5) therefore libtool should never remove a .manifest file except for the
one in .libs

but as a consequence of 2), there's no need for automake clean rules (or
libtool mode=clean rules) that address the .manifest file at all, other
than the one in .libs.

Have I got that right?

--
Chuck