Original thread(s) http://lists.gnu.org/archive/html/libtool-patches/2009-06/msg00058.html http://lists.gnu.org/archive/html/libtool-patches/2009-07/msg00002.html
Revived thread(s): http://lists.gnu.org/archive/html/libtool-patches/2010-02/msg00019.html http://lists.gnu.org/archive/html/libtool-patches/2010-03/msg00011.html I think where this thread left off, Ralf had posted some (incomplete?) texinfo documentation attempting to describe the whole UAC problem. I think Ralf planned to extend that texinfo to serve as a sort of "design document" for how we OUGHT to treat the issue, and then move on to rewriting a patch to implement the desired behavior. So...the subthread starting with the fourth link above is probably the place to start. In the third subthread, I *think* Ralf was leaning toward the following behavior/assumptions. I don't necessarily agree with these, but: a) We should care only about the manifest file associated with the cwrapper. It is up to the package maintainer to take care to provide an appropriate manifest for the ACTUAL exe. b) If they DO provide a manifest, the package maintainer is responsible for putting the appropriate rules in the Makefile to ensure that it gets copied to $builddir if builddir != srcdir. (However, the "copy over to builddir" only matters if you're NOT compiling the manifest into a binary resource and linking it directly into the app). b1) Since, if we need a wrapper, it will go in $builddir, then the cwrapper will "use" that one. b2) libtool should probably copy the manifest file into .lib/ so that the "real" exe will get a copy too. This may not work correctly if the "real" exe triggers the lt- prefixing rule (because then the name encoded in the body of the manifest won't match the actual name of the .exe). b3) For these reasons, it's probably best if the package maintainer also provides rules for "embedding" the manifest in binary form into the "real" exe. How these rules will deal with the whole lt-*.exe naming problem (recompiling the manifest object to specify the "true" exe name, and then relinking, on libtool --mode=install?) is an open question. b4) The maintainer is also responsible for creating a rule to clean up the (copy of) the manifest file in $builddir, if it is a copy of a custom file in $srcdir. c) If these do NOT provide a manifest, then libtool will autogenerate one for the use of the cwrapper only, never for the actual exe. Of course, this means that the actual exe, if it has a naughty name, will fail to execute -- whether installed or uninstalled. But, see a), above. c1) We should automatically clean up the manifest in $builddir/ if and only if that manifest was created by libtool. This probably requires a change to automake. Now, the above is a lot of easy-to-get-wrong custom automake stuff (and some libtool clients don't use automake, but instead have handcrafted Makefile.in's -- but I guess we don't care much about them). And, because it would require a lot of custom, windows-only rules, many upstream projects would be hesitant to accept such patches. We could make this easier by adding, at least, .rc->.o (hmm: msvc, .rc->.res) rules to Automake. If we had that, then perhaps we could link the resource object (whether .o or .res) into the wrapper as well. But this pre-supposes that all such apps with "naughty" names MUST be patched to add: a .rc file specifying the manifest a manifest file -- perhaps populated as an AC_OUTPUT .in-file. but probably the Automake changes would include the necessary win32-platform AM_CONDITIONAL and emit appropriate rules to conditionally add the .rc file to prog_SOURCES. [[err, what if the .rc file is ALSO an AC_OUTPUT-generated file? How will Automake know to use BUILT_SOURCES? ]] But at least that's less invasive (in terms of the patch upstream projects would have to accept to their Makefile.am's) than all-custom. Ok, over to you, Ralf! I said, summarizing Ralf: http://lists.gnu.org/archive/html/libtool-patches/2010-02/msg00035.html > 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. Ralf said: http://lists.gnu.org/archive/html/libtool-patches/2010-03/msg00031.html > 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.) -- Chuck
