[PATCH] [CXX] Use correct export_dynamic_flag_spec for PE-COFF $hosts

[Charles Wilson]

* libltdl/m4/libtool.m4 (_LT_LANG_CXX_CONFIG) [cygwin*|mingw*|pw32*|cegcc*]:
Define export_dynamic_flag_spec as -Wl,--export-all-symbols here as well
(see commit 5f2bbb494a2753afb2878c399cfd8316b7403a5b).

Signed-off-by: Charles Wilson ...
---
Originally posted by Yaakov Selkowitz on the cygwin list. Seems
obvious to me, especially given 5f2bbb494a2753afb2878c399cfd8316b7403a5b.

OK to push?

--
Chuck



 libltdl/m4/libtool.m4 |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 0777d4d..f45a630 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -5632,6 +5632,7 @@ if test $_lt_caught_CXX_error != yes; then
 # _LT_TAGVAR(hardcode_libdir_flag_spec, $1) is actually meaningless,
 # as there is no search path for DLLs.
 _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='-L$libdir'
+_LT_TAGVAR(export_dynamic_flag_spec, $1)='${wl}--export-all-symbols'
 _LT_TAGVAR(allow_undefined_flag, $1)=unsupported
 _LT_TAGVAR(always_export_symbols, $1)=no
 _LT_TAGVAR(enable_shared_with_static_runtimes, $1)=yes
-- 
1.6.3.2

Re: [PATCH] [cygwin|mingw] Create UAC manifest files.

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Charles Wilson on 6/30/2009 6:05 AM:
 The attached patch was submitted on the cygwin list by Yaakov
 Selkowitz, and is currently included in the cygwin libtool
 distribution.  It has received some objection (notably by Peter
 Rosin) over there, but I'll let him speak for himself -- I'm
 posting this version explicitly to attract comments so the patch
 can be refined.

Do we need to worry about deleting *.manifest files at the appropriate
'make *clean' level?

 + # 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

Would it be more efficient to use tee or cp, rather than two calls to
func_emit_exe_manifest?  Does the .manifest need +x permissions?

- --
Don't work too hard, make some time for fun as well!

Eric Blake e...@byu.net
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkpKB6oACgkQ84KuGfSFAYC+VgCfV2wYdwWoAfFG6FwW3bWoHX8w
YJ8AoKOdTq0oK/17Esf373iu0XSme87/
=vYc5
-END PGP SIGNATURE-

Re: [PATCH] [cygwin|mingw] Create UAC manifest files.

[Kai Tietz]

libtool-patches-bounces+kai.tietz=onevision@gnu.org wrote on 
30.06.2009 14:05:47:

 * libltdl/config/ltmain.m4sh (func_emit_exe_manifest): New function.
 (func_mode_link) [cygwin|mingw]: Create manifest files for wrapper
 and target exe when target name matches heuristic that triggers
 UAC problems for newer win32 OSs.
 
 Signed-off-by: Charles Wilson libt...@cwilson.fastmail.fm
 ---
 The attached patch was submitted on the cygwin list by Yaakov
 Selkowitz, and is currently included in the cygwin libtool
 distribution.  It has received some objection (notably by Peter
 Rosin) over there, but I'll let him speak for himself -- I'm
 posting this version explicitly to attract comments so the patch
 can be refined.
 
 From Yaakov's original submission
 http://cygwin.com/ml/cygwin/2009-06/msg00620.html
 (the rest of the thread is instructive as well):
 
  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.
 
 Comments?
 
 --
 Chuck
 
 
  libltdl/config/ltmain.m4sh |   33 +
  1 files changed, 33 insertions(+), 0 deletions(-)
 
 diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
 index ebd3909..1e8635e 100644
 --- a/libltdl/config/ltmain.m4sh
 +++ b/libltdl/config/ltmain.m4sh
 @@ -3604,6 +3604,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
 +?xml version=1.0 encoding=UTF-8 standalone=yes?
 +assembly xmlns=urn:schemas-microsoft-com:asm.v1 
manifestVersion=1.0
 +  assemblyIdentity version=1.0.0.0
 + processorArchitecture=X86
 + name=$host_os.$PROGRAM.$outputname
 + type=win32/
 +
 +  !-- Identify the application security requirements. --
 +  trustInfo xmlns=urn:schemas-microsoft-com:asm.v3
 +security
 +  requestedPrivileges
 +requestedExecutionLevel level=asInvoker uiAccess=false/
 +  /requestedPrivileges
 +/security
 +  /trustInfo
 +/assembly
 +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 ()
 @@ -7434,6 +7460,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
 -- 
 1.6.3.2
 
 
 

Hi,

I like this manifest feature, but could do the same for amd64 windows 
targets? Or at least make sure that manifest isn't emmited for this 
targets as it would prevent that application is launchable, if there is a 
32-bit manifest.

Cheers,
Kai

|  (\_/)  This is Bunny. Copy and paste Bunny
| (='.'=) into your signature to help him gain
| ()_() world domination.

Re: [PATCH] [cygwin|mingw] Create UAC manifest files.

[Ralf Wildenhues]

* Charles Wilson wrote on Tue, Jun 30, 2009 at 02:05:47PM CEST:
 * libltdl/config/ltmain.m4sh (func_emit_exe_manifest): New function.
 (func_mode_link) [cygwin|mingw]: Create manifest files for wrapper
 and target exe when target name matches heuristic that triggers
 UAC problems for newer win32 OSs.

I haven't looked at the actual patch, nor is the following an approval
or rejection on the general idea.

Can you explain what the semantics for UAC files are (pointer is
sufficient)?

Why does gcc but not msvc need them?

Can you convey the need for copyright assignment requirements for
nontrivial patches?

Can you explain why automake should not need support for UAC files,
and if it does need them, in what cases?  (Note I'm not asking you
to write a patch.)

Can people replying to messages on this list please cut down the quoted
text to a sensible size?

Thanks,
Ralf

Re: DESTDIR install on hppa-hpux #3

[Ralf Wildenhues]

Hello Michael,

I'm pretty short on review time ATM; sorry for not providing a detailed
review.

* Michael Haubenwallner wrote on Mon, Jun 29, 2009 at 11:22:31AM CEST:
 
 Ok, here's the third way of supporting DESTDIR on hppa-hpux, now without
 the +cdp linker flag (#2), but using the absolute target libdir in the
 'internal name' instead, to fix the security issue of #1.

Using absolute paths seems like a step backward, with all the world
wanting relocatable packages more than anything.  I don't think we
should go that way unless we cannot help it at all.  But maybe I have
misunderstood you latest approach?

Thanks,
Ralf

Re: [PATCH] [cygwin|mingw] Create UAC manifest files.

[libtool]

On Tue, 30 Jun 2009 16:23 +0200, Ralf Wildenhues wrote:
 * Charles Wilson wrote on Tue, Jun 30, 2009 at 02:05:47PM CEST:
  * libltdl/config/ltmain.m4sh (func_emit_exe_manifest): New function.
  (func_mode_link) [cygwin|mingw]: Create manifest files for wrapper
  and target exe when target name matches heuristic that triggers
  UAC problems for newer win32 OSs.

 Can you explain what the semantics for UAC files are (pointer is
 sufficient)?

On Vista and newer, applications whose names match certain patterns (yay
for security!) are automatically assumed to be installers, and when
launched trigger Vista's User Account Control (e.g. privilege elevation
prompt).  However, in many cases you don't WANT privelege elevation --
why should the BSD-flavor install.exe require Administrator privileges
when you do a make install prefix=/home/my-stuff?  So, you can add a
manifest file with the same name as the executable, following a
specified template [*], that suppresses the privelege elevation prompt.

These manifests need not be separate files.  MSVC provides a special
tool that can compile them into resource objects that are then linked in
to the executable (or DLL).  With binutils, you can instead create a
second file with the following content:

1 24 MOVEABLE PURE progname.manifest

and then

$ windres progname.rc progname.rc.o
$ ld -o new-progname.exe progname.exe progname.rc.o
$ mv new-progname.exe progname.exe

But that's overkill for the libtool cwrappers, and probably also for
most other executables...

http://cygwin.com/ml/cygwin/2006-12/msg00518.html (and thread)
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1020271SiteID=1mode=1
(and thread)

And remember, you only NEED manifests at all if your application's NAME
matches certain patterns that look like they might be installers.
Yeesh.

 Why does gcc but not msvc need them?

It does. cl.exe has a flag that causes it to automatically invoke the
MSVC manifest tool (mt? I forget), AND link the resulting object into
the target.  Peter's libtool patches exploit this functionality, which
is why he *doesn't* want libtool to create external xml manifests for
that toolchain.

 Can you convey the need for copyright assignment requirements for
 nontrivial patches?

[*] The bulk of the patch is a template: there is only one way to format
this manifest to accomplish the goal. Thus, the creative content of the
patch is about 7-8 lines, so it's still a (tiny change) IMO.  But IANAL,
so...

 Can you explain why automake should not need support for UAC files,
 and if it does need them, in what cases?  (Note I'm not asking you
 to write a patch.)

It probably should -- but the rules are very different, even require
different tools, depending on the toolchain in use. AND sometimes you
want external xml manifests, other times (if your toolchain supports it)
you want compiled-in resources.  AND you only ever need them if the
Windows version is Vista or above AND the target filename matches
certain patterns.  I'm not sure that we can yet formulate the correct
procedure, in order to codify it as The Way that automake should do
it.

This is why Yaakov took the easy way out: for the magic executable
names, just always create in-place external xml manifests and don't even
bother to install them -- because they are not always needed on the
destination system, even if they may be needed on the build system.
 
--
Chuck

Re: [PATCH] [cygwin|mingw] Create UAC manifest files.

[Charles Wilson]

Eric Blake wrote:
 Do we need to worry about deleting *.manifest files at the appropriate
 'make *clean' level?

Hmm. Yes, the one in the build directory (for the wrapper, or the real
exe if building without dependencies on uninstalled DLLs) probably
should be.  The one in .libs/ not so much, because the catchall rm -rf
.libs will take care of it.

 +# 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
 
 Would it be more efficient to use tee or cp, rather than two calls to
 func_emit_exe_manifest?

Well, you're not guaranteed to have tee on MSYS.  The current code is
two forks: each function call forks a 'cat' process.  Either of your
proposals is also two forks: one 'cat', and one 'tee' or 'cp'.  So I
don't think it makes much difference.

 Does the .manifest need +x permissions?

I seem to recall that it does, but I'm not sure.

--
Chuck

Re: [PATCH] [CXX] Use correct export_dynamic_flag_spec for PE-COFF $hosts

[Charles Wilson]

Ralf Wildenhues wrote:
 Yes but can you please check that you don't need to add another 3
 patches for F77, FC, GCJ?

Well, the whole tag-based mechanism in libtool makes my teeth ache, but
as far as I can tell we don't actually have separate cases for those
other languages' linker requirements at present.  There's just C++, and
everything else:

m4_defun([_LT_LINKER_SHLIBS],
...
m4_if([$1], [CXX], [
c++ _LT_TAGVAR stuff
], [
other _LT_TAGVAR stuff
]])

Presuming there WAS a need for a separate setting for F77 or FC or
GCJ...er, where exactly would such things go?

--
Chuck