Re: UAC .manifest files
Den 2009-06-20 09:05 skrev Charles Wilson: Peter Rosin wrote: ltwrappers are just replacing the old wrappers AFAIK, and those are indeed needed by the MSVC patches, so that premise has already changed. If you can't be bothered to cooperate with those patches then I can switch to arguing that cccl (wrapper for MSVC) is supported by libtool. When you use cccl with a contemporary MSVC, MSVC will create the manifest for you. You should not overwrite the manifest generated by MSVC in that case. So again, please special case this to only be active for gcc (and whatever else needs it). Peter: I don't know why you're arguing with Yaakov; you really should be talking to me. I've already said I want to take this to the libtool list and discuss it there, and you can be sure it won't go into *libtool-master* until everybody is happy. I just wanted to make sure the patch worked and didn't break any of the tests (Bzzt. bad formatting failed sh.test) before I posted it, on Yaakov's behalf, for discussion on libtool-patches. Now, today's cygwin-only libtool release did include Yaakov's patch, but only for this reason: we're coming up on the cygwin-1.7 release and I know that Yaakov has about 1500 packages to rebuild in the very near future. Anything to make that easier... Plus, because I've decided to start pushing again -- hard -- to get my existing patches into libtool-master, I *know* I'll be rolling a new libtool release fairly soon. So, today's -4/-13 packages will have a pretty short shelf life. If they cause a problem for you, don't use them... -3/-12 aren't going anywhere, and you'll probably like -5/-14 better. I argu because I'm peeved. One primary reason and a very secondary reason. Primary: Yaakov has been ignoring me. Hard! * http://www.cygwin.com/ml/cygwin/2008-11/msg00298.html * http://www.cygwin.com/ml/cygwin/2008-12/msg00448.html * http://www.cygwin.com/ml/cygwin/2009-06/msg00417.html I have made several attempts, but I have gotten zero feedback. Nothing whatsoever. Incredibly rude IMHO. How difficult is it to acknoledge a bug report? Even to say it is invalid (if that's the case)? I would have been satisfied with any response I'd gotten (well, any reasonably civil response), but total silence simply isn't acceptable. Secondary: Sitting for years waiting for libtool patches to get in while other libtool patches whissle past in the fast lane will do strange things to you. You mentioning patches that have not been merged for a couple of months seem /almost/ like a bad joke (I know it's not comparable, but that's what it tastes like). The combination of the above two and the fact that I'm only human made me lash out. As an aside, it's a little ridiculous to badger Yaakov, or anybody else, about cooperating with out-of-tree patches. Now, it's not your fault that they are still out of tree. Frankly, I have no idea why they weren't merged months ago (same as certain OTHER patches I could mention). But until they are merged, and MSVC is fully supported...well, you know the score. Ok, I was out of line about the MSVC patches and that was admittedly a bad start. I was somewhat upset. But do note that you apparently missed the passage in the second message where I explain that the changes are harming existing setups. My point is that the patch is not perfect and that it needs fixing. I don't care who fixes it, as long as it's not me. I wouldn't be surprised if I'm the one who fixes it eventually though. Cheers, Peter -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: UAC .manifest files
Peter Rosin wrote: > ltwrappers are just replacing the old wrappers AFAIK, and those are > indeed needed by the MSVC patches, so that premise has already changed. > > If you can't be bothered to cooperate with those patches then I can > switch to arguing that cccl (wrapper for MSVC) is supported by libtool. > When you use cccl with a contemporary MSVC, MSVC will create the > manifest for you. You should not overwrite the manifest generated > by MSVC in that case. > > So again, please special case this to only be active for gcc (and > whatever else needs it). Peter: I don't know why you're arguing with Yaakov; you really should be talking to me. I've already said I want to take this to the libtool list and discuss it there, and you can be sure it won't go into *libtool-master* until everybody is happy. I just wanted to make sure the patch worked and didn't break any of the tests (Bzzt. bad formatting failed sh.test) before I posted it, on Yaakov's behalf, for discussion on libtool-patches. Now, today's cygwin-only libtool release did include Yaakov's patch, but only for this reason: we're coming up on the cygwin-1.7 release and I know that Yaakov has about 1500 packages to rebuild in the very near future. Anything to make that easier... Plus, because I've decided to start pushing again -- hard -- to get my existing patches into libtool-master, I *know* I'll be rolling a new libtool release fairly soon. So, today's -4/-13 packages will have a pretty short shelf life. If they cause a problem for you, don't use them... -3/-12 aren't going anywhere, and you'll probably like -5/-14 better. As an aside, it's a little ridiculous to badger Yaakov, or anybody else, about cooperating with out-of-tree patches. Now, it's not your fault that they are still out of tree. Frankly, I have no idea why they weren't merged months ago (same as certain OTHER patches I could mention). But until they are merged, and MSVC is fully supported...well, you know the score. -- Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: UAC .manifest files
Den 2009-06-18 21:22 skrev Yaakov (Cygwin/X): On 18/06/2009 13:31, Peter Rosin wrote: There is a pending patch for libtool that adds MSVC support. That patch will not need this, so please special case this to only be active for gcc (and whatever else needs it). AFAICS from your patches, you're not using ltwrappers right now. If wrappers_required=no (which you may need to set), func_mode_link() exit()s before this point, so it should be moot. If that premise changes, it will need to be dealt with then; I can only work with what's in libtool right now. ltwrappers are just replacing the old wrappers AFAIK, and those are indeed needed by the MSVC patches, so that premise has already changed. If you can't be bothered to cooperate with those patches then I can switch to arguing that cccl (wrapper for MSVC) is supported by libtool. When you use cccl with a contemporary MSVC, MSVC will create the manifest for you. You should not overwrite the manifest generated by MSVC in that case. So again, please special case this to only be active for gcc (and whatever else needs it). Cheers, Peter -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: UAC .manifest files
Yaakov (Cygwin/X) wrote: > On 18/06/2009 10:56, Yaakov (Cygwin/X) wrote: >> Since I already have a libtool patch pending, I'll see if I can fix this >> as well. > > Here's a patch. Chuck? > Looks ok. I'll include this in the next cygwin-libtool release, but I want to have some discussion on the libtool list with Peter Rosin about his concerns before pushing it there. -- Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: UAC .manifest files
On 18/06/2009 13:31, Peter Rosin wrote: There is a pending patch for libtool that adds MSVC support. That patch will not need this, so please special case this to only be active for gcc (and whatever else needs it). AFAICS from your patches, you're not using ltwrappers right now. If wrappers_required=no (which you may need to set), func_mode_link() exit()s before this point, so it should be moot. If that premise changes, it will need to be dealt with then; I can only work with what's in libtool right now. Yaakov -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: UAC .manifest files
Den 2009-06-18 20:14 skrev Yaakov (Cygwin/X): On 18/06/2009 10:56, Yaakov (Cygwin/X) wrote: Since I already have a libtool patch pending, I'll see if I can fix this as well. Here's a patch. Chuck? There is a pending patch for libtool that adds MSVC support. That patch will not need this, so please special case this to only be active for gcc (and whatever else needs it). (but why do I bother responding to your mails when you don't respond to mine?) Cheers, Peter -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: UAC .manifest files
On 18/06/2009 10:56, Yaakov (Cygwin/X) wrote:
Since I already have a libtool patch pending, I'll see if I can fix this
as well.
Here's a patch. Chuck?
Yaakov
--- origsrc/libtool-2.2.7a/libltdl/config/ltmain.m4sh 2009-06-15 00:06:10.0 -0500
+++ src/libtool-2.2.7a/libltdl/config/ltmain.m4sh 2009-06-18 11:49:49.913954500 -0500
@@ -3748,6 +3748,32 @@ EOF
}
# end: func_emit_cwrapperexe_src
+# func_emit_exe_manifest
+# emit a Win32 UAC manifest for executable on stdout
+# Must ONLY be called from within func_mode_link because
+# it depends on a number of variable set therein.
+func_emit_exe_manifest()
+{
+cat <
+
+
+
+
+
+
+
+
+
+
+
+
+EOF
+}
+
# func_win32_import_lib_p ARG
# True if ARG is an import lib, as indicated by $file_magic_cmd
func_win32_import_lib_p ()
@@ -7578,6 +7604,13 @@ EOF
$opt_dry_run || {
# 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
+ case $output_name in
+ *instal*|*patch*|*setup*|*update*)
+ func_emit_exe_manifest > $cwrapper.manifest
+ func_emit_exe_manifest > $output_path/$objdir/$output_name.exe.manifest
+ ;;
+ esac
$cwrapper --lt-dump-script > $func_ltwrapper_scriptname_result
else
func_emit_wrapper no > $func_ltwrapper_scriptname_result
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: UAC .manifest files
On 04/06/2009 11:11, Dave Korn wrote:
Sounds like a job for libtool, not automake. :)
Unfortunately, it looks like that's not a joke after all.
Look at func_mode_link (omitting some lines for clarity):
*cygwin* | *mingw* )
cwrappersource="$output_path/$objdir/lt-$output_name.c"
cwrapper="$output_path/$output_name.exe"
$RM $cwrappersource $cwrapper
func_emit_cwrapperexe_src > $cwrappersource
$LTCC $LTCFLAGS -o $cwrapper $cwrappersource
$STRIP $cwrapper
$cwrapper --lt-dump-script > $func_ltwrapper_scriptname_result
IOW, the cwrapper source is created and built, then the cwrapper is run
to create the ltwrapper ($objdir/${output_name}_ltshwrapper). But if
the target .exe has one of those names that trigger UAC, the last step
fails and the ltwrapper is empty. So not only can you not run the
program in-place, but worse, during install, the cwrapper is installed
instead of the real program, which obviously isn't very helpful.
So yes, in order for libtool to work with UAC, libtool needs to generate
a .manifest for both the $cwrapper in the $output_path (*before* the
lt-dump-script call) AND the real program in $objdir, so that running
in-place works. Whether it's libtool's responsibility to *install* the
latter is debatable.
Since I already have a libtool patch pending, I'll see if I can fix this
as well.
Chuck, any thoughts?
Yaakov
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: UAC .manifest files
Yaakov (Cygwin/X) wrote: > On 04/06/2009 08:19, Charles Wilson wrote: >> Spiro Trikaliotis wrote: >> >>> - let my.manifest be the manifest file >>> - Generate a .rc file with the line: >>>1 RT_MANIFEST "my.manifest" >>> - Let the resource compiler handle the .rc file, and let windres merge >>>the info into the executable. >> >> Sounds like a job for automake, not gcc. I don't see anything here >> http://autoconf-archive.cryp.to/macros-by-category.html#AUTOMAKE yet, >> tho. > > I concur; this is not within the realm of gcc to handle by itself. > > There are a number of GTK+ packages which include windres .rc files, but > it takes all sorts of automake hacking to do it (all within an > AM_CONDITIONAL, of course). Sounds like a job for libtool, not automake. :) cheers, DaveK -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: UAC .manifest files
On 04/06/2009 08:19, Charles Wilson wrote: Spiro Trikaliotis wrote: - let my.manifest be the manifest file - Generate a .rc file with the line: 1 RT_MANIFEST "my.manifest" - Let the resource compiler handle the .rc file, and let windres merge the info into the executable. Sounds like a job for automake, not gcc. I don't see anything here http://autoconf-archive.cryp.to/macros-by-category.html#AUTOMAKE yet, tho. I concur; this is not within the realm of gcc to handle by itself. There are a number of GTK+ packages which include windres .rc files, but it takes all sorts of automake hacking to do it (all within an AM_CONDITIONAL, of course). As for packages which don't use autotools, good luck. Either way, we don't want to go that route. Yaakov -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: UAC .manifest files
Spiro Trikaliotis wrote: > - let my.manifest be the manifest file > - Generate a .rc file with the line: > 1 RT_MANIFEST "my.manifest" > - Let the resource compiler handle the .rc file, and let windres merge > the info into the executable. Sounds like a job for automake, not gcc. I don't see anything here http://autoconf-archive.cryp.to/macros-by-category.html#AUTOMAKE yet, tho. -- Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: UAC .manifest files
Hello, * On Thu, Jun 04, 2009 at 10:25:51AM +0200 Corinna Vinschen wrote: > And, no, I have no idea how to generate inline manifests :} Taking from a project (Note: I did not write the code in the first place, so I might be missing the gory details): - let my.manifest be the manifest file (http://vice-emu.svn.sourceforge.net/viewvc/vice-emu/trunk/vice/src/arch/win32/vice.manifest?revision=20487&view=markup) - Generate a .rc file with the line: 1 RT_MANIFEST "my.manifest" (lines 69ff from http://vice-emu.svn.sourceforge.net/viewvc/vice-emu/trunk/vice/src/arch/win32/res.rc?revision=20736&view=markup) - Let the resource compiler handle the .rc file, and let windres merge the info into the executable. (lines 432ff from http://vice-emu.svn.sourceforge.net/viewvc/vice-emu/trunk/vice/src/arch/win32/Makefile.am?revision=20930&view=markup Regards, Spiro. -- Spiro R. Trikaliotis http://opencbm.sf.net/ http://www.trikaliotis.net/ http://www.viceteam.org/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: UAC .manifest files
On Jun 3 19:25, Yaakov S wrote: > Some additional googling revealed that you also mentioned that the > manifests need to be executable[2]. > > The attached patch is what I have in mind. It won't apply to SVN trunk > yet due to other uncommitted patches in the queue, but I need to fix > that soon to get a long-overdue release out the door. Anything else > that I may not be aware of before I commit this? At a first glance that looks good. I'm not aware of anything else besides of the executable bit. Btw., in the long run it would be cool if gcc would be able to generate executables with inline manifests using just a command line option. First of all, we would get rid of the extra manifest files, and second, copying such an executable to another dir wouldn't show surprising results. And, no, I have no idea how to generate inline manifests :} Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: UAC .manifest files
On 03/06/2009 03:11, Corinna Vinschen wrote:
I never saw more than exactly this list.
Got it (and with "instal" with one L).
I don't know if it matters, but it certainly doesn't hurt either. As a
suggestion, when automating this, the name could be constructed like
this:
Organization=Cygwin
Division=
Name=
As for why, IIRC you mentioned[1] before that the manifests are cached;
I suppose the name= attribute would be used in the cached data, hence
the requirement to be unique.
Some additional googling revealed that you also mentioned that the
manifests need to be executable[2].
The attached patch is what I have in mind. It won't apply to SVN trunk
yet due to other uncommitted patches in the queue, but I need to fix
that soon to get a long-overdue release out the door. Anything else
that I may not be aware of before I commit this?
[1] http://www.cygwin.com/ml/cygwin/2008-11/msg00163.html
[2] http://www.cygwin.com/ml/cygwin-apps/2008-08/msg00148.html
Yaakov
Index: bin/cygport.in
===
--- bin/cygport.in (revision 6306)
+++ bin/cygport.in (working copy)
@@ -1123,6 +1156,7 @@
# __prepinfo
# __prepman
# __prepstrip
+# __prepuac
# __prepvargames
# __prep_empty_dirs
# __prep_libtool_modules
@@ -1371,13 +1419,8 @@
# *.so: Apache2 modules, OCaml stublibs, Ruby modules
# *.oct: Octave modules
- for exe in $(find * -type f -name '*.dll' -o -name '*.exe' -o -name
'*.so' -o -name '*.oct')
+ for exe in $(find * -type f -writable -a \( -name '*.dll' -o -name
'*.exe' -o -name '*.so' -o -name '*.oct' \))
do
- if [ ! -w ${exe} ]
- then
- continue
- fi
-
# OCaml bytecode must not be stripped
# this test generates false positives with the ocaml core and
# compilers, but should otherwise be accurate
@@ -1404,6 +1447,29 @@
done
}
+__prepuac() {
+ local exe exename;
+
+ cd ${D};
+
+ echo "Preparing executables for UAC:";
+
+ for exe in $(find * -type f -executable -a \( -name '*instal*.exe' -o
-name '*patch*.exe' -o -name '*setup*.exe' -o -name '*update*.exe' \))
+ do
+ exename=${exe##*/};
+
+ # Mono assemblies may already include .manifest files.
+ if [ ! -e ${exe}.manifest ]
+ then
+ echo "${exe}";
+ sed -e "s|@PKGNAME@|${PN//.}|" \
+ -e "s|@APPNAME@|${exename%.exe}|" \
+ ${_privdatadir}/uac-manifest.in >
${exe}.manifest
+ chmod +x ${exe}.manifest
+ fi
+ done
+}
+
__prep_symlinks() {
local l l_src
@@ -1443,12 +1504,13 @@
__prepvargames;
__prep_empty_dirs;
__prepstrip;
+ __prepuac;
__prep_libtool_modules;
}
# protect functions
readonly -f __prepdoc __prepetc __prepman __prepinfo __prepvargames
__prep_empty_dirs \
-__prepstrip __prep_symlinks __prep_libtool_modules __src_postinst
+__prepstrip __prepuac __prep_symlinks __prep_libtool_modules
__src_postinst
Index: data/Makefile.am
===
--- data/Makefile.am(revision 6446)
+++ data/Makefile.am(working copy)
@@ -1,4 +1,8 @@
-dist_pkgdata_DATA = cygport.nanorc mirrors sample.cygport
+dist_pkgdata_DATA = \
+ cygport.nanorc \
+ mirrors \
+ sample.cygport \
+ uac-manifest.in
bashcompletiondir = /etc/bash_completion.d
dist_bashcompletion_DATA = cygport-bash-completion
Index: data/uac-manifest.in
===
--- data/uac-manifest.in(revision 0)
+++ data/uac-manifest.in(revision 0)
@@ -0,0 +1,16 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: UAC .manifest files
On Jun 3 10:11, Corinna Vinschen wrote: > On Jun 2 23:21, Yaakov S wrote: > > I think the best solution is to let cygport detect susceptible apps > > and generate .manifest files automatically. > > > > 1. AFAICS, this affects EXEs with names containing "install", "patch", > > "setup", or "update". Are there any more patterns? > > I never saw more than exactly this list. With a small change: s/install/instal/ Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: UAC .manifest files
On Jun 2 23:21, Yaakov S wrote: > I think the best solution is to let cygport detect susceptible apps > and generate .manifest files automatically. > > 1. AFAICS, this affects EXEs with names containing "install", "patch", > "setup", or "update". Are there any more patterns? I never saw more than exactly this list. > 2. According to MSDN[1], the name attribute of the assemblyIdentity > subelement should be uniquely named in a Organization.Division.Name > format. Our existing manifests don't do that; should we? Does it > matter? I don't know if it matters, but it certainly doesn't hurt either. As a suggestion, when automating this, the name could be constructed like this: Organization=Cygwin Division= Name= Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
UAC .manifest files
I'm up and running again, this time with Windows 7 RC x64 (at least for now), so I'm getting my first intro to the joys of UAC, which is fortunately more sane in Win7 than it is in Vista. I now realize that there are a number of packages, in both the distro and Ports, which still need .manifest files added for their binaries. I think the best solution is to let cygport detect susceptible apps and generate .manifest files automatically. 1. AFAICS, this affects EXEs with names containing "install", "patch", "setup", or "update". Are there any more patterns? 2. According to MSDN[1], the name attribute of the assemblyIdentity subelement should be uniquely named in a Organization.Division.Name format. Our existing manifests don't do that; should we? Does it matter? [1] http://msdn.microsoft.com/en-us/library/aa374191(VS.85).aspx Yaakov -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
