[PATCH] Add test case for 69e77671 (cwrapper PATH manipulation order)
* tests/cwrapper.at: Add new test 'cwrapper and installed shared
libraries.'
---
This patch was actually proposed by Roumen Petrov here:
http://lists.gnu.org/archive/html/bug-libtool/2009-12/msg00037.html
He mentioned here:
http://lists.gnu.org/archive/html/libtool-patches/2010-09/msg00222.html
that 69e77671 would actually fix the error exposed by this test. I
ran this test both with and without 69e77671; without 69e77671 this
test fails (cygwin), but with it the new test passes. Examination
shows that Roumen's test is exactly what is needed to verify that
the problem fixed by 69e77671 does not regress; his test explicitly
verifies that a newly built DLL (more generally, shared library)
is used at runtime in preference to an installed version.
tests/cwrapper.at | 70 +
1 files changed, 70 insertions(+), 0 deletions(-)
diff --git a/tests/cwrapper.at b/tests/cwrapper.at
index 248c0c0..ff3d04f 100644
--- a/tests/cwrapper.at
+++ b/tests/cwrapper.at
@@ -134,3 +134,73 @@ done
AT_CLEANUP
+
+AT_SETUP([cwrapper and installed shared libraries])
+AT_KEYWORDS([libtool])
+
+# make sure existing libtool is configured for shared libraries
+AT_CHECK([$LIBTOOL --features | grep 'disable shared libraries' exit 77],
+[1], [ignore])
+
+# FIXME with shared_fails for this test on AIX
+# copy from link-order2.at:
+eval `$LIBTOOL --config | $EGREP '^(shlibpath_var|allow_undefined_flag)='`
+
+undefined_setting=-no-undefined
+shared_fails=no
+case $host_os,$LDFLAGS,$allow_undefined_flag in
+aix*,*-brtl*,*) ;;
+aix*) shared_fails=yes ;;
+darwin*,*,*-flat_namespace*) undefined_setting= ;;
+darwin*,*,*) shared_fails=yes ;;
+esac
+# end of copy from link-order2.at
+
+LDFLAGS=$LDFLAGS $undefined_setting
+
+inst=`pwd`/inst
+libdir=$inst/lib
+bindir=$inst/bin
+mkdir $inst $libdir $bindir
+
+# we must build foo library in a separate directory to avoid on some
+# platforms shared library to be loaded from current directory
+
+mkdir foo
+cd foo
+# build and install old library version
+AT_DATA([a.c], [[
+int liba_ver (void) { return(1); }
+]])
+$LIBTOOL --mode=compile --tag=CC $CC $CPPFLAGS $CFLAGS -c a.c
+$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -version-info=0.0.0 -o liba.la
-rpath $libdir a.lo
+$LIBTOOL --mode=install $lt_INSTALL liba.la $libdir
+
+# build a new library version
+AT_DATA([a.c], [[
+int liba_ver (void) { return(2); }
+]])
+$LIBTOOL --mode=compile --tag=CC $CC $CPPFLAGS $CFLAGS -c a.c
+$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -version-info=0.0.0 -o liba.la
-rpath $libdir a.lo
+
+cd ..
+
+# build and run test application
+AT_DATA([m.c], [[
+extern int liba_ver (void);
+int main (void)
+{
+ int r = (liba_ver () == 2) ? 0 : 1;
+ return(r);
+}
+]])
+
+$LIBTOOL --mode=compile --tag=CC $CC $CPPFLAGS $CFLAGS -c m.c
+
+$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o m1$EXEEXT m.$OBJEXT foo/liba.la
+LT_AT_EXEC_CHECK([./m1], [0], [ignore], [ignore], [])
+
+$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o m2$EXEEXT m.$OBJEXT foo/liba.la
-L$inst/lib
+LT_AT_EXEC_CHECK([./m2], [0], [ignore], [ignore], [])
+
+AT_CLEANUP
--
1.7.1
Re: [PATCH] [cygwin|mingw] Create UAC manifest files.
On Wed, 01 Jul 2009 18:55 +0200, Ralf Wildenhues wrote: * Peter Rosin wrote on Wed, Jul 01, 2009 at 09:05:53AM CEST: On Tue, 30 Jun 2009 16:23 +0200, Ralf Wildenhues wrote: Why does gcc but not msvc need them? cl.exe will generate the manifest file all by itself, regardless of executable name. My gripe was that any file created by libtool will overwrite the file generated by cl.exe and I think cl.exe will do a better job of creating the manifest. My msvc patches then has code to embed the manifest into the executable using mt (manifest tool), but that is immaterial to this discussion. Have you guys considered adding manifest file functionality to GCC? I haven't. Frankly, I'd rather see 4.x stabilize on cygwin with the current feature set, than try to add new ones right now. The reason cl.exe has the manifest functionality built in, is because as of VS2005, the runtime library (be it msvcrt80.dll, or msvcrp80.dll, or whatever) is NOT identified, located, and loaded based on its name and the path search rules we all know and love. Instead, a manifest resource is used to determine EXACTLY which patch-level version of the non-interoperable versions of msvcrt80.dll is required by the application (as identified by a GUID in the resource). You can have many different versions installed in SxS (side by side) directories under C:\Windows\, and none of them need (or should) be in your PATH. This is Microsoft's solution to DLL hell. [no comment...] For gcc, we don't *NEED* manifests for every single pe[i]-i386 image. We only need them for a small selection of unluckily-named exes, and then only when they are executed on Vista or above. -- Chuck
Re: [PATCH] [cygwin|mingw] Create UAC manifest files.
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] fix dlpreopen with --disable-static
On Thu, 13 Nov 2008 22:09:07 +0100, Ralf Wildenhues said: OK, how about this. It is a slight backward incompatibility, but not a large one: - --verbose undoes --silent *and* enables verbose output (that one with func_verbose), - --no-silent *only* undoes --silent, It should still be bearable for the user, in the sense that if you use --verbose rather than --no-silent, it's not a big problem. And we don't have to think about what --verbose --verbose --silent causes, we can just make the last one win. If you agree, then let's proceed this way. I don't mind who writes the patch. That sounds good to me. The help output would need a little re-wording: # --quiet, --silentdon't print informational messages # -v, --verboseprint informational messages (default) # --no-silent ??? I'll let you do that. g B) func_win32_libid() gives some confusing errors to users when (a) using recursive make, and (b) MAKEFLAGS does not contain $OBJDUMP. Add a diagnostic error message, rather than allowing $SED to die a horrible death. [...] Actually, this may no longer be necessary given the _LT_DECL_OBJDUMP changes (I /said/ this was an old patch). Here's the thread: http://cygwin.com/ml/cygwin/2008-09/msg00552.html Ah, ok, thanks. I'll remove any of these bits from the revised patch(es). Well, one reason I sat on this for so long was the 'fallback' mechanism for deducing the dll name from the import library was just so...hideous. And it wasn't a fallback -- it was the only mechanism since I hadn't yet enhanced dlltool. Do you steer dlltool development, BTW? No. I've contributed a few patches over the years to dlltool and binutils, but that's it. The only reason to allow it is because (hopefully) that ugly fallback code can get flagged with a warning, and maybe in a year or so get removed. Sounds like a good idea. Of course, first I need to revise the dlltool patch and get it accepted; there have been some comments on the binutils list. Well, that, and it fixes a test that currently fails. Which one, and can you post output for failure as well as success with the patch, please? demo-exec after demo-shared, in the old test suite. I'll post the output(s) tonight or tomorrow. Hmm. I reviewed this whole function, and only when done I asked myself this, more radical question: we go great lengths here to find out a name. Iff we have a *.la file to go with the implib, can't we just *know* the name? I mean, we produced that thing, it has the expected name, no? That's what the *.la file was designed for: to not have to look into the binary files for information. Or is this purely for import libraries not created with libtool (and people who throw away *.la files)? The information (e.g. library to dlpreopen) is passed in $dlprefiles. But, if that filename is .la: func_mode_link(): ... dlfiles|dlprefiles) if test $preload = no; then # Add the symbol object into the linking commands. func_append compile_command @SYMFILE@ func_append finalize_command @SYMFILE@ preload=yes fi case $arg in *.la | *.lo) ;; # We handle these cases below. ... ...much later... *.la) # A libtool-controlled library. if test $prev = dlfiles; then # This library was specified with -dlopen. dlfiles=$dlfiles $arg prev= elif test $prev = dlprefiles; then # The library was specified with -dlpreopen. dlprefiles=$dlprefiles $arg prev= else deplibs=$deplibs $arg fi continue ;; So far, so good. But then we eventually source the .la file, and end up here (this is, in fact, what's happening in the demo-shared case): # This library was specified with -dlpreopen. if test $pass = dlpreopen; then if test -z $libdir test $linkmode = prog; then func_fatal_error only libraries may -dlpreopen a convenience library: \`$lib' fi # Prefer using a static library (so that no silly _DYNAMIC symbols # are required to link). if test -n $old_library; then newdlprefiles=$newdlprefiles $dir/$old_library # Keep a list of preopened convenience libraries to check # that they are being used correctly in the link pass. test -z $libdir \ dlpreconveniencelibs=$dlpreconveniencelibs $dir/$old_library # Otherwise, use the dlname, so that lt_dlopen finds it. elif test -n $dlname; then newdlprefiles=$newdlprefiles $dir/$dlname else newdlprefiles=$newdlprefiles $dir/$linklib fi fi # $pass = dlpreopen We've stored the DLL name as just ONE of the entries in $newdlprefiles
Re: [Patch] cwrapper invokes target directly
On Wed, 30 Apr 2008 10:12:36 -0500 (CDT), Bob Friesenhahn xxx said: I have a MinGW cross-compiler hosted off of FreeBSD 7.0. Presumably I can run Wine on it. I know that Linux has special hooks in order to automatically run Windows executables using Wine. Is the Wine execution support dependent on this Linux feature? No, the compile phase requires the $build (linux, unix?) executable 'winepath' only, and does not rely on the binfmt extension present in linux. The wrapper itself is already running in the emulation environment, and uses Win32 spawnv (and other functions from the win32 C runtime library) to launch the target executable -- within the same emulation env, so no need for binfmt there, either. However, actually running the test suite is going to try to invoke the wrapper.exe, so that would require binfmt (or another solution; I have ideas). This may (or may not) represent a regression from 1.5.x+explicit $TARGETSHELL specification, I'm not sure. When I (later) add support for $build=*nix+wine, $host=cygwin cross-compiles, I'll also need either the 'wine' executable (which itself is a $build=*nix program) or the binfmt extension, because I need to execute 'cygpath' *in the $host environment* for step 2 of the following conversion: *nix [$build] path --( winepath )-- native win32 [$host] path --( 'cygpath -u' under wine )-- cygwin [$host] path All of these difficulties and ripples are why I originally thought 'eliminate the wrapper script entirely for $host=cygwin|mingw' was a libtool-2.4 project. However, the current libtool-2.2 behavior was an unreported (!) regression over 1.5.x, and the conversation last week seemed to imply that it was important enough to try to fasttrack before 2.4...but that doesn't mean it will or can get completely fixed in one simple patch. It may require iteration and public testing -- over a few 2.2.x releases -- before we get it right. :-( -- Chuck
Re: [cygwin] cwrapper emits wrapper script
On Wed, 06 Jun 2007 09:43:50 -0500, Peter O'Gorman said: I'm lazy and would like to avoid work as much as possible, Gary has already asked if you'd like a commit bit, I'm hoping you'll agree, then all we'll need to do is say ok and you can commit your changes yourself. As long as somebody other than me inspects/approves (...or rejects) my patches, I'm happy to turn the crank to check them in myself. -- Chuck
Re: New libtool is in the GCC and Src trees.
On Tue, 29 May 2007 12:36:13 -0600, Tom Tromey said: Charles == Charles Wilson writes: Charles Secondly, the entire contents of libjava/libltdl/ need to be Charles updated. I don't think we need to do this. libgcj uses libltdl primarily as a portable wrapper for dlopen. As such it works just fine as is. Well, it /did/ -- until the new-libtool merge. Now there seem to be build problems. So /something/ needs fixin'. g Also, libgcj has some local libltdl patches as well. Then they should be submitted upstream -- if they are still necessary. There have been a lot of improvements in libltdl since 1.4.x and even 1.5.x. Why do you think it should be updated? Because unless I am very mistaken, new libtool.m4 + old ltdl.m4(other old libltdl stuff) is not a tested/supported configuration -- it /may/ work, but... Will aclocal pull in the the old libtool.m4 (perhaps from /usr/share/aclocal/ if it can't find one with the required serial number closer at hand?) at the request of the old ltdl.m4? Will it instead complain about serial number mismatch? Will libjava/aclocal.m4 end up with both/conflicting versions of various LT macros, or worse a hodgepodge of some LT macros from old libtool.m4 and some from new libtool.m4? Or will libjava/aclocal get only new libtool.m4 LT macros, but not define some of the (old) ones that old ltdl.m4 relies on? I don't know the answers to these questions -- but I do know that new libtool.m4 + new libltdl stuff has a pretty thorough test suite. I hate to say this, but perhaps, for now: (1) the libjava/ portions of Steve's patch should be backed out (2) local copies of what USED to be in toplevel put into libjava/ (3) libjava's configure.ac and Makefile.am's modified again to NOT look in toplevel (4) re-auto* in libjava/* just so that libjava can get back to status quo ante. Because it looks like there really is a whole lot of work left to be done before libjava is ready to use the new libtool, thanks to the overlooked use of libltdl. -- Chuck
