UAC .manifest files

Yaakov (Cygwin/X) yselkowitz@users.sourceforge.net
Thu Jun 18 16:58:00 GMT 2009


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/



More information about the Cygwin mailing list