Mail Archives: cygwin/2009/06/18/11:57:08
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/
- Raw text -