Re: Repost: [PATCH] [cygwin|mingw] Create UAC manifest files.
Hi Dave,
thanks for your quick review! I've incorporated all changes not
addressed below.
* Dave Korn wrote on Tue, Mar 16, 2010 at 11:24:42AM CET:
On 16/03/2010 06:17, Ralf Wildenhues wrote:
and updating of system-wide software. The level of privileges required
for some executable program to accomplish its task may be designated by
the program developer by means of a manifest file (@pxref{Manifest
Files}) or a compiled-in Windows resource file (@pxref{Resource Files}),
among other possibilities, and among many other system-specific metadata
that may be added to these files, such as program icons.
This is slightly confusing, I don't think it quite makes it clear that
what's going on is that the manifest file can be put into the resource file.
How about something along the lines of ...
[ ... snip ... ] The level of privileges required
for some executable program to accomplish its task may be designated by
the program developer by means of a manifest file (@pxref{Manifest
Files}), which may either be installed in the same directory alongside
the executable, or can be built directly in by adding the manifest file
as a binary resource in a Windows resource file (@pxref{Resource Files})
that is included in the executable's final link.[ ... snip ... ]
That's better, but it makes it sounds like the resource file is a
binary, and built directly in sounds unobvious to me. Is binary
resource a technical term? Would using just resource be enough?
AFAIU, the resource file (*.rc) is a simple hand-written text file,
which may refer to the manifest file (like a .c file includes a header),
then gets compiled by windres to an object file and linked in like any
other object. Right?
This means, if your executable happens to match any of
those strings, even if it has no need for elevated privileges otherwise,
will needlessly prompt for a password, and if granted, work under
super-user access.
Complex run-on sentence construction. How about just
[ ... snip ... ] If your executable does not need elevated privileges, but
happens to match any of those strings, the OS will needlessly prompt for a
password, and (if granted) run the executable with greater privileges than an
ordinary user application is supposed to have.[ ... snip ... ]
BTW, if the password is not given correctly, then will the program run
under lesser privileges or will it not run at all? I think we should
document that as well, because either outcome has implications for the
developer.
And maybe here:
It is possible to turn off this hack by means of a
manifest file or compiled-in resource.
... mention that you can indeed also turn it on (well, request elevated
privilege) for files that have names that /do not/ match the patterns listed
above.
Certainly.
This is where I'm at now.
I'm beginning to think the best and cleanest way is to get .rc handling
into Automake (should be straightforward), and just recomment to always
use that, or a hand-written .rc.$(OBJEXT) rule if windres is present.[1]
(Of course that still leaves libtool semantics to do for this issue, but
at least it releaves us from much thought about where the source tree
is, which libtool --mode=link does not know or care about so far.)
Cheers,
Ralf
[1] Incidentally, that's exactly what we do here in an application also
targeted for w32.
@node Windows pecularities
@chapter Windows pecularities
Autotools strive to provide some level of support for the various
Microsoft DOS and Windows systems. The GNU
@command{config.guess} command recognizes and names few different
environments built upon this operating system and suitable for autotools
usage, such as Cygwin, MinGW, DJGPP, or Interix. Besides the GCC ports
for these systems, other compilers may be supported to varying degree.
Compared to most Unix-like systems, these operating systems differ in
several respects. Some of them may be handled transparently by the
autotools, but many of them require adaptation by the developer.
@node UAC
@section User Account Control (UAC)
The Microsoft Vista and all later versions of Windows provide increased
default privilege control over earlier versions for certain operations
such as the installation and updating of system-wide software.
The level of privileges required
for some executable program to accomplish its task may be designated by
the program developer by means of a manifest file (@pxref{Manifest
Files}), which may either be installed in the same directory alongside
the executable, or can be built directly in by adding the manifest file
as a resource in a Windows resource file (@pxref{Resource Files})
that is included in the executable's final link.
Now, there exists a large amount of legacy software built for older
versions of this operating system, which is not aware of these privilege
controls. In order to allow these older programs to continue to work on
the newer system
Re: Repost: [PATCH] [cygwin|mingw] Create UAC manifest files.
Den 2010-03-19 07:18 skrev Ralf Wildenhues: AFAIU, the resource file (*.rc) is a simple hand-written text file, which may refer to the manifest file (like a .c file includes a header), then gets compiled by windres to an object file and linked in like any other object. Right? That's not the whole truth. If you use Visual Studio, the primary way to edit the resources is not to hack the text of the .rc file (you certainly *can*, but it's not the recommended usage pattern). I think most Windows IDEs have resource editors to make it more painless to design dialogs and draw icons etc. Also, the resource compiler supplied by MS (i.e. RC.EXE) doesn't compile to an ordinary object file, instead it produces a .RES file (whatever format that is, maybe it's COFF but I don't think so) which you then feed to the linker. So, the usage pattern is equivalent but warped (as usual). I don't know if the text in the Windows section should address these nits though... Cheers, Peter -- They are in the crowd with the answer before the question. Why do you dislike Jeopardy?
Re: Repost: [PATCH] [cygwin|mingw] Create UAC manifest files.
On 19/03/2010 06:18, Ralf Wildenhues wrote:
[ ... snip ... ] The level of privileges required
for some executable program to accomplish its task may be designated by
the program developer by means of a manifest file (@pxref{Manifest
Files}), which may either be installed in the same directory alongside
the executable, or can be built directly in by adding the manifest file
as a binary resource in a Windows resource file (@pxref{Resource Files})
that is included in the executable's final link.[ ... snip ... ]
That's better, but it makes it sounds like the resource file is a
binary, and built directly in sounds unobvious to me. Is binary
resource a technical term? Would using just resource be enough?
Actually, I was wrong:
AFAIU, the resource file (*.rc) is a simple hand-written text file,
which may refer to the manifest file (like a .c file includes a header),
then gets compiled by windres to an object file and linked in like any
other object. Right?
Yep, that's basically it. The resource file defines objects from a certain
number of pre-defined categories, such as strings, icons and other small
bitmaps, and various struct-like things such as version infos; these are
compiled (along with some management data) into a .rsrc section that is then
linked into the exe.
A binary resource is a catch-all object type that just includes any old
arbitrary binary data you like, it's a bag-o-bytes.
However I misunderstood the docs I looked up. MS have defined a specialised
type of resource for manifests, you don't just throw them in as a blob, and
that means you just create a manifest resource type entry and include the
manifest xml data as a string directly within it; it doesn't refer to a
separate file on disk at all. So better wording would be:
... or can be built directly in by adding the XML contents of the file as a
manifest resource in a Windows resource file (@pxref{Resource Files}) that is
included ...
BTW, if the password is not given correctly, then will the program run
under lesser privileges or will it not run at all? I think we should
document that as well, because either outcome has implications for the
developer.
I don't have a handy installation to find out on. I would guess that if you
enter the password incorrectly it asks you to try again, just like a regular
windows log-on dialog, and if you click Cancel, the application doesn't
launch. I'll see if I can find some more solid info anywhere.
This is where I'm at now.
Looking good, apart from the above only one nit:
If your executable does not need elevated privileges, but happens to match any
of those strings, the OS will prompt for a password. If granted,
run the executable with greater privileges than an ordinary user
application is supposed to have; otherwise, the program will not be started.
There's a word or two gone missing between granted and run!
cheers,
DaveK
Re: Repost: [PATCH] [cygwin|mingw] Create UAC manifest files.
On 03/16/2010 04:24 AM, Dave Korn wrote:
On 16/03/2010 06:17, Ralf Wildenhues wrote:
Microsoft @sc{dos} and Windows systems. The @sc{gnu}
Should capitalise DOS and GNU.
@sc{} does the capitalization for you. This is correct texinfo usage.
--
Eric Blake ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: Repost: [PATCH] [cygwin|mingw] Create UAC manifest files.
On 17/03/2010 17:14, Eric Blake wrote:
On 03/16/2010 04:24 AM, Dave Korn wrote:
On 16/03/2010 06:17, Ralf Wildenhues wrote:
Microsoft @sc{dos} and Windows systems. The @sc{gnu}
Should capitalise DOS and GNU.
@sc{} does the capitalization for you. This is correct texinfo usage.
Thanks, that's a new one to me. OTOH, the texinfo documentation for @sc
suggests that GNU is an acronym, and so I would think is DOS, so maybe that
tag should be used instead of sc.
cheers,
DaveK
Re: Repost: [PATCH] [cygwin|mingw] Create UAC manifest files.
On 03/17/2010 01:23 PM, Dave Korn wrote:
On 17/03/2010 17:14, Eric Blake wrote:
On 03/16/2010 04:24 AM, Dave Korn wrote:
On 16/03/2010 06:17, Ralf Wildenhues wrote:
Microsoft @sc{dos} and Windows systems. The @sc{gnu}
Should capitalise DOS and GNU.
@sc{} does the capitalization for you. This is correct texinfo usage.
Thanks, that's a new one to me. OTOH, the texinfo documentation for @sc
suggests that GNU is an acronym, and so I would think is DOS, so maybe that
tag should be used instead of sc.
Not to mention the current debate on the automake list on whether GNU or
@acronym{GNU} is preferred in GNU manuals (Karl Berry is arguing that it
is simpler to blindly write GNU, rather than either @acronym{GNU} or
@sc{gnu}, and that the differences in font rendering in dvi/pdf files
aren't worth worrying about by just going with the solution with the
least typing).
--
Eric Blake ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: Repost: [PATCH] [cygwin|mingw] Create UAC manifest files.
This issue is complex enough that it warrants some explanation.
We should help our users on that front.
I'm not the w32 expert in any measure, so here's a chunk of texinfo
text that I've just run down now, without much integration, and by
stealing some of the explanations of others.
I was going to finish it first, but given that it already took me this
long to come up with this, maybe it's better to go ahead and post it.
(I hope to get a suggestion for intended libtool semantics posted RSN).
Thanks, and sorry for the delay,
Ralf
@node Windows pecularities
@chapter Windows pecularities
Autotools strive to provide some level of support for the various
Microsoft @sc{dos} and Windows systems. The @sc{gnu}
@command{config.guess} command recognizes and names few different
environments built upon this operating system and suitable for autotools
usage, such as Cygwin, MinGW, DJGPP, Interix. Besides the GCC ports for
these systems, other compilers may be supported to varying degree.
Compared to most Unix-like systems, these operating systems differ in
several respects. Some of them may be handled transparently by the
autotools, but many of them require adaptation by the developer.
@node UAC
@section User Account Control (UAC)
The Microsoft Vista version of Windows provides increased default
privilege control for certain operations such as the installation
and updating of system-wide software. The level of privileges required
for some executable program to accomplish its task may be designated by
the program developer by means of a manifest file (@pxref{Manifest
Files}) or a compiled-in Windows resource file (@pxref{Resource Files}),
among other possibilities, and among many other system-specific metadata
that may be added to these files, such as program icons.
Now, there exists a large amount of legacy software built for older
versions of this operating system, which is not aware of these privilege
controls. In order to allow these older programs to continue to work on
the newer system without failing due to lack of privileges, a special
compatibility hack was devised that lets the operating system assume
programs with names containing the substrings @code{instal},
@code{setup}, @code{update}, or @code{patch} would deal with system
program installation and as such should prompt for super-user
(Administrator) privileges.
Now, unfortunately, this hack applies to all software, not just old
legacy programs. This means, if your executable happens to match any of
those strings, even if it has no need for elevated privileges otherwise,
will needlessly prompt for a password, and if granted, work under
super-user access. It is possible to turn off this hack by means of a
manifest file or compiled-in resource.
Now, @command{libtool} ...
@node Manifest Files
@subsection Manifest Files
...
@node Resource Files
@subsection Resource Files
...
Re: Repost: [PATCH] [cygwin|mingw] Create UAC manifest files.
On 16/03/2010 06:17, Ralf Wildenhues wrote:
Microsoft @sc{dos} and Windows systems. The @sc{gnu}
Should capitalise DOS and GNU.
The Microsoft Vista version of Windows provides increased default
Should refer to Vista and all later versions.
and updating of system-wide software. The level of privileges required
for some executable program to accomplish its task may be designated by
the program developer by means of a manifest file (@pxref{Manifest
Files}) or a compiled-in Windows resource file (@pxref{Resource Files}),
among other possibilities, and among many other system-specific metadata
that may be added to these files, such as program icons.
This is slightly confusing, I don't think it quite makes it clear that
what's going on is that the manifest file can be put into the resource file.
How about something along the lines of ...
[ ... snip ... ] The level of privileges required
for some executable program to accomplish its task may be designated by
the program developer by means of a manifest file (@pxref{Manifest
Files}), which may either be installed in the same directory alongside
the executable, or can be built directly in by adding the manifest file
as a binary resource in a Windows resource file (@pxref{Resource Files})
that is included in the executable's final link.[ ... snip ... ]
Now, there exists [ ... snip ... ]
Now, unfortunately, [ ... snip ... ]
Now, @command{libtool} [ ... snip ... ]
That comes across a bit awkwardly. The explanation is correct in details,
just the wording needs a tweak. Apart from avoiding the repetition of 'Now,'
I'd also suggest rewording to this bit:
This means, if your executable happens to match any of
those strings, even if it has no need for elevated privileges otherwise,
will needlessly prompt for a password, and if granted, work under
super-user access.
Complex run-on sentence construction. How about just
[ ... snip ... ] If your executable does not need elevated privileges, but
happens to match any of those strings, the OS will needlessly prompt for a
password, and (if granted) run the executable with greater privileges than an
ordinary user application is supposed to have.[ ... snip ... ]
And maybe here:
It is possible to turn off this hack by means of a
manifest file or compiled-in resource.
... mention that you can indeed also turn it on (well, request elevated
privilege) for files that have names that /do not/ match the patterns listed
above.
cheers,
DaveK
Re: Repost: [PATCH] [cygwin|mingw] Create UAC manifest files.
On Tue, Feb 23, 2010 at 2:20 AM, Yaakov (Cygwin/X) yselkow...@users.sourceforge.net wrote: On 2010-02-21 06:11, Ralf Wildenhues wrote: 3) This patch will overwrite a .manifest file created in the build dir, thus may break a package that create them through some other means. I can't see any package generating one of these. If a package uses a .manifest file, it will be hand-written, shipped in $srcdir, and compiled in to the application, so the bigger worry is making sure that with in-tree builds we don't overwrite an existing file. Will any of this break the situation where a compiler generates a manifest file? Both the Intel and PGI native Windows compilers that I use create manifest file right next to DLLs and EXEs. I believe the thread is referring to executables that match specific names, but I just want to make sure it does not affect the general case. Chris Note that here, I'm not speaking about the manifest below .libs, and I understand that that is necessary as well, and that if the user creates one, it is probably a bug that we don't use that for the to-be-installed program; not sure if it's always harmless to then-reuse that for the cwrapper as well. It better not be, because with an in-tree build, a shipped .manifest will not only be compiled in to the real executable (so a copy in .libs shouldn't be necessary) but will end up being used by the cwrapper as well. 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. Any package which uses libtool and creates programs whose names match the specified pattern requires these .manifest files. As for which libtoolized packages require this right now, I am aware of *at least* the following: bind desktop-file-utils GeoIP gtk+ rarian WindowMaker This list is based on installed program names, but there might very well be more packages whose noinst_PROGRAMS or check_PROGRAMS trigger this. The alternative to this patch would be workarounds in said packages to add explicit code to create embedded manifests (that then apply to the to-be-installed program). We'd still need a manifest for the cwrapper. Hmm, that means waiting for (2) is moot, unless we embed a manifest into the cwrapper. Ugh. Remember that the packages with which we are dealing are designed for *NIX systems and therefore won't have their own manifests nor would an invasive patch to add a compiled-in manifest likely be accepted. Yaakov Cygwin Ports
Re: Repost: [PATCH] [cygwin|mingw] Create UAC manifest files.
Christopher Hulbert wrote: On Tue, Feb 23, 2010 at 2:20 AM, Yaakov (Cygwin/X) wrote: On 2010-02-21 06:11, Ralf Wildenhues wrote: 3) This patch will overwrite a .manifest file created in the build dir, thus may break a package that create them through some other means. I can't see any package generating one of these. If a package uses a .manifest file, it will be hand-written, shipped in $srcdir, and compiled in to the application, so the bigger worry is making sure that with in-tree builds we don't overwrite an existing file. Will any of this break the situation where a compiler generates a manifest file? Both the Intel and PGI native Windows compilers that I use create manifest file right next to DLLs and EXEs. I believe the thread is referring to executables that match specific names, but I just want to make sure it does not affect the general case. I think the idea that Peter Rosin is pushing for, is that all of this manifest stuff would be 'switched on' only if $CC=gcc. The test would either be performed at runtime (e.g. additional case statements in ltmain.m4sh) or at configure time (e.g. put all the manifest-handling stuff into functions that are emitted into the libtool script by libtool.m4 -- and the not gcc version would be a no-op). However, these are relatively minor -- and easy to fix -- issues. Ralf's objections are more fundamental, so we need to deal with those first. -- Chuck
Re: Repost: [PATCH] [cygwin|mingw] Create UAC manifest files.
The only comment NOT addressed by this version is: Peter Rosin doesn't want this code activated for msvc, but I'm not sure this patch should be modified to guard against a compiler, whose support (in Peter's branch) has not itself yet been merged into master. And I don't know what symbol to use; maybe Peter's branch has a special variable that should be tested? I was thinking that a _LT_DECL variable should be added to libtool.m4 that instructed ltmain to enable this code branch instead of adding more compiler/system checks to ltmain. That would make it trivial to disable it where appropriate. And cl is already (allegedly) supported by libtool via the cccl script, this code will add further rot to that support if some kind of tool chain discrimination is not added. Cheers, Peter
Re: Repost: [PATCH] [cygwin|mingw] Create UAC manifest files.
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
Re: Repost: [PATCH] [cygwin|mingw] Create UAC manifest files.
On 2010-02-21 06:11, Ralf Wildenhues wrote: 3) This patch will overwrite a .manifest file created in the build dir, thus may break a package that create them through some other means. I can't see any package generating one of these. If a package uses a .manifest file, it will be hand-written, shipped in $srcdir, and compiled in to the application, so the bigger worry is making sure that with in-tree builds we don't overwrite an existing file. Note that here, I'm not speaking about the manifest below .libs, and I understand that that is necessary as well, and that if the user creates one, it is probably a bug that we don't use that for the to-be-installed program; not sure if it's always harmless to then-reuse that for the cwrapper as well. It better not be, because with an in-tree build, a shipped .manifest will not only be compiled in to the real executable (so a copy in .libs shouldn't be necessary) but will end up being used by the cwrapper as well. 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. Any package which uses libtool and creates programs whose names match the specified pattern requires these .manifest files. As for which libtoolized packages require this right now, I am aware of *at least* the following: bind desktop-file-utils GeoIP gtk+ rarian WindowMaker This list is based on installed program names, but there might very well be more packages whose noinst_PROGRAMS or check_PROGRAMS trigger this. The alternative to this patch would be workarounds in said packages to add explicit code to create embedded manifests (that then apply to the to-be-installed program). We'd still need a manifest for the cwrapper. Hmm, that means waiting for (2) is moot, unless we embed a manifest into the cwrapper. Ugh. Remember that the packages with which we are dealing are designed for *NIX systems and therefore won't have their own manifests nor would an invasive patch to add a compiled-in manifest likely be accepted. Yaakov Cygwin Ports
Re: Repost: [PATCH] [cygwin|mingw] Create UAC manifest files.
Hello, * Charles Wilson wrote on Sun, Feb 21, 2010 at 07:31:15AM CET: [cygwin|mingw] Create UAC manifest files. * libltdl/config/ltmain.m4sh (func_emit_exe_manifest): New function. (func_mode_link) [cygwin|mingw]: Create manifest files for wrapper and target exe when target name matches heuristic that triggers UAC problems for newer win32 OSs. Clean up $cwrapper.manifest on error. Ensure manifest files have executable permission. (func_mode_uninstall): Clean up manifest files. Various reports by Eric Blake, Kai Tietz, and Cesar Strauss. I have the following issues/questions with this patch: 0) I still haven't fully understood the semantics here. Are the manifest files only needed at link editor time or at runtime? 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? If the former, then why doesn't a --mode=link remove the manifest file before exiting (non-interrupted)? 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*. Neither this nor manifest creation and usage, nor (0) are covered in the libtool testsuite. But need to be. 2) automake/lib/am/progs.am does not use --mode=clean for cleaning programs which means the manifest files for cwrappers will be leftover. I expect this to cause a distcheck failure. So Automake needs to be fixed. I'm willing to change Automake to use 'libtool --mode=clean' for when new-enough libtool is used, but the comment ## FIXME: In the future (i.e., when it works) it would be nice to delegate ## this task to `libtool --mode=clean'. still requires some history digging for cases where this doesn't work as expected. These cases should be investigated and covered by the libtool testsuite. 3) This patch will overwrite a .manifest file created in the build dir, thus may break a package that create them through some other means. Note that here, I'm not speaking about the manifest below .libs, and I understand that that is necessary as well, and that if the user creates one, it is probably a bug that we don't use that for the to-be-installed program; not sure if it's always harmless to then-reuse that for the cwrapper as well. IIUC then this particular regression could be worked around inside a package by using an embedded manifest, since that will override an external .manifest file. Right? Of course libtool shouldn't remove a user-created manifest file as in (1) at all. Not sure how to fix that if (0) is runtime. 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 alternative to this patch would be workarounds in said packages to add explicit code to create embedded manifests (that then apply to the to-be-installed program). We'd still need a manifest for the cwrapper. Hmm, that means waiting for (2) is moot, unless we embed a manifest into the cwrapper. Ugh. 5) I'd prefer a nod from Peter R. as to whether this is fixable easily: The only comment NOT addressed by this version is: Peter Rosin doesn't want this code activated for msvc, but I'm not sure this patch should be modified to guard against a compiler, whose support (in Peter's branch) has not itself yet been merged into master. And I don't know what symbol to use; maybe Peter's branch has a special variable that should be tested? Anyway, IF this patch should be modified to protect msvc, I'd sure like somebody to tell me how that should be done: # note: this script will not be executed, so do not chmod. if test x$build = x$host ; then + # Create the UAC manifests first if necessary (but the + # manifest files must have executable permission regardless). like this, maybe: if [ $CC != msvc ]; then + case $output_name in + *instal*|*patch*|*setup*|*update*) Or tell me that such protection should be deferred until Peter's stuff is merged? Well, my guess is that this should be addressed at the time master is next merged to pr-msvc-support, either in the merge or in a followup commit. To prevent even more friction caused from my incredibly slow progress on libtool, releases, and merging of said branch, I'd try to help with that merge if that helps, and would like to apologize again to Peter. 6) + case $host in + i?86-*-* ) echo ' processorArchitecture=x86' ;; + ia64-*-* ) echo ' processorArchitecture=ia64' ;; + x86_64-*-* ) echo ' processorArchitecture=amd64' ;;
Re: Repost: [PATCH] [cygwin|mingw] Create UAC manifest files.
Ralf Wildenhues wrote:
* Charles Wilson wrote on Sun, Feb 21, 2010 at 07:31:15AM CET:
[cygwin|mingw] Create UAC manifest files.
* libltdl/config/ltmain.m4sh (func_emit_exe_manifest): New
function.
(func_mode_link) [cygwin|mingw]: Create manifest files for
wrapper and target exe when target name matches heuristic that
triggers UAC problems for newer win32 OSs. Clean up
$cwrapper.manifest on error. Ensure manifest files have
executable permission.
(func_mode_uninstall): Clean up manifest files.
Various reports by Eric Blake, Kai Tietz, and Cesar Strauss.
I have the following issues/questions with this patch:
0) I still haven't fully understood the semantics here. Are the
manifest files only needed at link editor time or at runtime?
runtime.
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.
The RTTD for packages which are intended to build executables with
bad names is to handle the manifest stuff themselves.
Well, the REAL RTTD is for automake to do it, in the non-libtool case,
but...that gets very sticky, very quickly. And it really doesn't
address the issue with libtool-built exes (and wrapper exes).
This implementation is intended as a convenience so that the /build/
doesn't die for hard-to-explain reasons, on Vista and above. Without
it, the build dies because we try to use wrapper.exe --dump-script to
generate the wrapper script, and that fails on Vista when the
wrapper.exe has a bad name and no .manifest. We chose to use
--dump-script, and not func_emit_wrapper(), because this way allows us
to detect, and fail, if the wrapper exe doesn't build correctly for some
reason. Arguably, not having a .manifest when you need one IS a failure
-- because if ${builddir}/wrapper.exe fails to execute due to the lack
of one, then ${builddir}/.libs/actual.exe won't have a .manifest either,
and IT will fail, as well. Detect errors early, and all that...
I'm ignoring entirely the compiled-in .manifest resource issue. That's
just too ugly for words (below).
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}. But, to be
effective, the .manifest file must be in the same directory as the
identically-named .exe. This leaves two open issues:
a) what to do when during mode=build, when ${builddir}==${srcdir}, AND
the upstream source provides an explicit .manifest file
b) what to do during 'make clean' and/or libtool --mode=clean.
If the former, then why doesn't a --mode=link remove the manifest file
before exiting (non-interrupted)?
n/a
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? (It would add .libs/*.manifest
to $rmfiles only after an explicit existence check, but no corresponding
'have libtool comment' check...)
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/.
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.
Neither this nor manifest creation
and usage, nor (0) are covered in the libtool testsuite. But need to
be.
So...deliberately create an exe with a bad name, and make sure it's
executable (plus an explicit hey does the .manifest file exist check)?
For the no-.manifest in srcdir, and with-.manifest in srcdir cases?
Then, for an exe with a good name, verify that no .manifest is
created, unless there already is one in ${srcdir}, and in that case,
that the .manifest does NOT have the magic comment string.
So, a total of four tests.
Would that be sufficient?
2) automake/lib/am/progs.am does not use --mode=clean for cleaning
programs which means the manifest files for cwrappers will be leftover.
I expect this to cause a distcheck failure.
Ugh. You're right.
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
Re: Repost: [PATCH] [cygwin|mingw] Create UAC manifest files.
Charles Wilson wrote: 2010-02-21 Yaakov Selkowitz ... Charles Wilson ... [cygwin|mingw] Create UAC manifest files. * libltdl/config/ltmain.m4sh (func_emit_exe_manifest): New function. (func_mode_link) [cygwin|mingw]: Create manifest files for wrapper and target exe when target name matches heuristic that triggers UAC problems for newer win32 OSs. Clean up $cwrapper.manifest on error. Ensure manifest files have executable permission. (func_mode_uninstall): Clean up manifest files. Various reports by Eric Blake, Kai Tietz, and Cesar Strauss. FWIW, test suite results (tested in combination with: UAC manifest patch Pass runtime flags thru to gcc Wrapper script documentation No regressions relative to http://lists.gnu.org/archive/html/libtool-patches/2010-02/msg00010.html cygwin == All old tests passed. New tests: 48: deplib in subdir FAILED (deplib-in-subdir.at:140) 69: dlloader API FAILED (dlloader-api.at:416) 92: C++ exception handling FAILED (exceptions.at:254) 102: Run tests with low max_cmd_len FAILED (cmdline_wrap.at:43) mingw: == FAIL: tests/tagdemo-make.test FAIL: tests/tagdemo-make.test FAIL: tests/tagdemo-make.test FAIL: tests/tagdemo-make.test 27: C++ convenience archives FAILED (convenience.at:99) 48: deplib in subdir FAILED (deplib-in-subdir.at:140) 62: C++ subdir-objects FAILED (am-subdir.at:148) 89: (C++ template tests):simple template test FAILED (template.at:89) 90: (C++ template tests):template test with subdirs FAILED (template.at:241) 91: C++ static constructors FAILED (ctor.at:62) 92: C++ exception handling FAILED (exceptions.at:242) 102: Run tests with low max_cmd_len FAILED (cmdline_wrap.at:43) (No, I don't expect C++ on mingw to get better simply because of this change. You'd still need to correct the *packaging* error in MinGW's 4.4.0 gcc package) Linux: == All test passed, in both the old and new testsuites.
Re: Repost: [PATCH] [cygwin|mingw] Create UAC manifest files.
Hi Charles,
* 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?
Well, the REAL RTTD is for automake to do it, in the non-libtool case,
but...that gets very sticky, very quickly. And it really doesn't
address the issue with libtool-built exes (and wrapper exes).
Yes, I've understood that.
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? 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?
(Never mind the need for a manifest below .libs, I fully understand and
agree with the need for that.)
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.
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.
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.
(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.
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.
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.
Neither this nor manifest creation
and usage, nor (0) are covered in the libtool testsuite. But need to
be.
So...deliberately create an exe with a bad name, and make sure it's
executable (plus an explicit hey does the .manifest file exist check)?
Well, simply cover all code paths in code you add, ensure all code paths
you modify are covered. So, if ltmain can create a manifest file, then
the testsuite should have a case where it does so and where it doesn't
do so. If ltmain checks for user-provided manifest file, then there
should be a case with a user-provided one and a case without. And we
should have an executable with a bad name and one with a good name.
And if all these binary decisions are intertwined in the ltmain code
decision paths, then it's better to not just test each of them
separately, but each combined. (That's one reason stresstest.at takes
so long to execute.)
This strategy is so universal. You may apply it to all future patch
submissions.
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 21 ];
+?LIBTOOL?then
+?LIBTOOL? rm -f ${p}${EXEEXT}.manifest
+?LIBTOOL?fi
+?LIBTOOL? done
That's even more ugly in my eyes.
As I said, I'm willing to live with a need for newer Automake for a
clean solution; in the
