This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]