Re: mdemo ltdl failure
Charles Wilson wrote: Charles Wilson wrote: Charles Wilson wrote: I'll whip up a patch and post it to the newlib list. So, I posted the following: http://sourceware.org/ml/newlib/2007/msg00271.html However, there's no telling how long it'll be before a new cygwin kernel is released that includes the patch, and besides, libtool ought to work on current and reasonably recent cygwin kernels. So, how should libtool address this issue in the interim? Always use libltdl's argz stuff on cygwin, until further notice: version check on uname, etc etc? If so, how do we induce that Here's my attempt: [snip long description of ugly runtime test] See http://lists.gnu.org/archive/html/libtool-patches/2007-03/msg00030.html After discussion with Bob F, I've reimplemented this fix without the actual runtime test. Instead, if $host_os is cygwin, and cygwin version is 1.5.24 or older, then force use of libltdl builtin argz. In all other cases (including cross), pre-existing detection rules apply. This is because the test is just too ugly for words, not to mention brittle. Trying to tease out malloc issues outside of a dedicated malloc testsuite is just plain silly. I'm still using the -export-symbols-regex .* fix for libmlib in tests/mdemo -- it's also included in this patch. Still true. TESTING: I've tested this under the following conditions: (1) broken cygwin kernel (1.5.24-2 used, but any older would do) --detects failure, builds successfully using libltdl's argz --resultant libraries also work after dropping in a fixed cygwin kernel. (2) fixed cygwin kernel (official snapshot from 20070330) --detects success, builds successfully using system argz --resultant libraries coredump if you drop in a broken cygwin kernel after the fact. This is expected: broken cygwin is broken precisely because its argz facility coredumps on argz_insert(). (3) fixed cygwin kernel, but with $lt_cv_sys_argz_works=no. --does not even try to run the test program, and successfully builds using libltdl's argz --resultant libraries works fine even after dropping in a broken cygwin kernel. Re-ran all of these tests under the specified conditions. Same results as the original patch. (4) linux (whose system argz is OK) --detects success, builds using system argz, works. (5) linux, but with $lt_cv_sys_argz_works=no. --doesn't run the test, and builds using libltdl argz. works. (6) mingw, which doesn't have any system argz facility at all --the test is not run --builds successfully with libltdl's argz Did not run these tests. configury and sourcecode paths unchanged from original path so these should obviously still work. But I'll retest if desired. New Changelog: 2007-03-17 Charles Wilson [EMAIL PROTECTED] * libltdl/argz_.h: ensure error_t definition is obtained in same mechanism system argz.h would have. * libltdl/libltdl/lt__glibc.h: also detect if SYSTEM_ARGZ_IS_BROKEN when determining whether to re#def argz* functions. * libltdl/m4/argz.m4: add new test to check if $host's argz facilities are known bad. * tests/mdemo/Makefile.am: -export-symbols-regex fix for libmlib. -- Chuck Index: libltdl/argz_.h === RCS file: /cvsroot/libtool/libtool/libltdl/argz_.h,v retrieving revision 1.6 diff -u -r1.6 argz_.h --- libltdl/argz_.h 4 Sep 2006 17:23:30 - 1.6 +++ libltdl/argz_.h 17 Mar 2007 06:09:46 - @@ -32,6 +32,8 @@ #define LT__ARGZ_H 1 #include stdlib.h +#define __need_error_t +#include errno.h #include sys/types.h #if defined(LTDL) Index: libltdl/libltdl/lt__glibc.h === RCS file: /cvsroot/libtool/libtool/libltdl/libltdl/lt__glibc.h,v retrieving revision 1.7 diff -u -r1.7 lt__glibc.h --- libltdl/libltdl/lt__glibc.h 26 Oct 2006 20:39:04 - 1.7 +++ libltdl/libltdl/lt__glibc.h 17 Mar 2007 06:09:49 - @@ -37,7 +37,7 @@ # include config.h #endif -#if !defined(HAVE_ARGZ_H) +#if !defined(HAVE_ARGZ_H) || defined(SYSTEM_ARGZ_IS_BROKEN) /* Redefine any glibc symbols we reimplement to import the implementations into our lt__ namespace so we don't ever clash with the system library if our clients use argz_* Index: libltdl/m4/argz.m4 === RCS file: /cvsroot/libtool/libtool/libltdl/m4/argz.m4,v retrieving revision 1.3 diff -u -r1.3 argz.m4 --- libltdl/m4/argz.m4 25 Mar 2006 11:05:02 - 1.3 +++ libltdl/m4/argz.m4 17 Mar 2007 06:09:50 - @@ -27,6 +27,38 @@ ARGZ_H= AC_CHECK_FUNCS([argz_append argz_create_sep argz_insert argz_next \ argz_stringify], [], [ARGZ_H=argz.h; AC_LIBOBJ([argz])]) + +dnl if have system argz functions, allow forced use of +dnl libltdl-supplied implementation (and default to
Re: mdemo ltdl failure
On Wed, 18 Apr 2007, Charles Wilson wrote: [snip long description of ugly runtime test] See http://lists.gnu.org/archive/html/libtool-patches/2007-03/msg00030.html After discussion with Bob F, I've reimplemented this fix without the actual runtime test. Instead, if $host_os is cygwin, and cygwin version is 1.5.24 or older, then force use of libltdl builtin argz. In all other cases (including cross), pre-existing detection rules apply. This new version is certainly more attractive than before. Presumably this special case can be safely removed after enough time has elapsed for the majority of Cygwin installs to be updated. Is the: libmlib_la_LDFLAGS = -no-undefined -export-symbols-regex .* statement portable? Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
[cygwin, libtool] use shell function to emit wrapper scripts and wrapper.exe source [Was: Re: .exe magic]
[Added libtool-patches to CC list. Discussion of this patch
should probably drop libtool and cygwin]
Ralf Wildenhues wrote:
* Charles Wilson wrote on Wed, Apr 18, 2007 at 08:49:31PM CEST:
Caveat: over a year after the message referenced above, but libtool2.0
is STILL in code-slush, so the desired fixes will have to wait until
after 2.0
... I'd prefer to see such a patch before deciding when it's good to put
it in.
Okay, here's the first bit. It's pretty simple. Testing is in progress
(and in conjuction with the new argz fix I just posted to
libtool-patches), but looks good so far: the new wrapper scripts are
identical to old ones generated without this patch.
--
Chuck
ChangeLog
2007-04-18 Charles Wilson [EMAIL PROTECTED]
* libltdl/config/ltmain.m4sh [func_mode_link]: move wrapper
script writing from here...
[func_emit_libtool_wrapper_script]: to this new function, and
write to stdout
[func_mode_link]: move cwrapper source code writing from here...
[func_emit_libtool_cwrapperexe_source]: to this new function,
and write to stdout
[func_mode_link]: call the two new functions and redirect to
appropriate file.
Index: libltdl/config/ltmain.m4sh
===
RCS file: /cvsroot/libtool/libtool/libltdl/config/ltmain.m4sh,v
retrieving revision 1.72
diff -u -r1.72 ltmain.m4sh
--- libltdl/config/ltmain.m4sh 10 Apr 2007 19:09:26 - 1.72
+++ libltdl/config/ltmain.m4sh 19 Apr 2007 01:05:30 -
@@ -1202,6 +1202,555 @@
}
}
+# func_emit_libtool_wrapper_script
+# emit a libtool wrapper script on stdout
+# don't directly open a file because we may want to
+# incorporate the script contents within a cygwin/mingw
+# wrapper executable. Must ONLY be called from within
+# func_mode_link because it depends on a number of variable
+# set therein.
+func_emit_libtool_wrapper_script ()
+{
+ $ECHO \
+#! $SHELL
+
+# $output - temporary wrapper script for $objdir/$outputname
+# Generated by $PROGRAM (GNU $PACKAGE$TIMESTAMP) $VERSION
+#
+# The $output program cannot be directly executed until all the libtool
+# libraries that it depends on are installed.
+#
+# This wrapper script should never be moved out of the build directory.
+# If it is, it will not operate correctly.
+
+# Sed substitution that helps us do robust quoting. It backslashifies
+# metacharacters that are still active within double-quoted strings.
+Xsed='${SED} -e 1s/^X//'
+sed_quote_subst='$sed_quote_subst'
+
+# Be Bourne compatible
+if test -n \\${ZSH_VERSION+set}\ (emulate sh) /dev/null 21; then
+ emulate sh
+ NULLCMD=:
+ # Zsh 3.x and 4.x performs word splitting on \${1+\[EMAIL PROTECTED]},
which
+ # is contrary to our usage. Disable this feature.
+ alias -g '\${1+\[EMAIL PROTECTED]}'='\[EMAIL PROTECTED]'
+ setopt NO_GLOB_SUBST
+else
+ case \`(set -o) 2/dev/null\` in *posix*) set -o posix;; esac
+fi
+BIN_SH=xpg4; export BIN_SH # for Tru64
+DUALCASE=1; export DUALCASE # for MKS sh
+
+# The HP-UX ksh and POSIX shell print the target directory to stdout
+# if CDPATH is set.
+(unset CDPATH) /dev/null 21 unset CDPATH
+
+relink_command=\$relink_command\
+
+# This environment variable determines our operation mode.
+if test \\$libtool_install_magic\ = \$magic\; then
+ # install mode needs the following variables:
+ generated_by_libtool_version='$macro_version'
+ notinst_deplibs='$notinst_deplibs'
+else
+ # When we are sourced in execute mode, \$file and \$ECHO are already set.
+ if test \\$libtool_execute_magic\ != \$magic\; then
+ECHO=\$qecho\
+file=\\$0\
+# Make sure echo works.
+if test \X\$1\ = X--no-reexec; then
+ # Discard the --no-reexec flag, and continue.
+ shift
+elif test \X\`{ \$ECHO '\t'; } 2/dev/null\`\ = 'X\t'; then
+ # Yippee, \$ECHO works!
+ :
+else
+ # Restart under the correct shell, and then maybe \$ECHO will work.
+ exec $SHELL \\$0\ --no-reexec \${1+\[EMAIL PROTECTED]}
+fi
+ fi\
+
+ $ECHO \
+
+ # Find the directory that this script lives in.
+ thisdir=\`\$ECHO \X\$file\ | \$Xsed -e 's%/[^/]*$%%'\`
+ test \x\$thisdir\ = \x\$file\ thisdir=.
+
+ # Follow symbolic links until we get to the real thisdir.
+ file=\`ls -ld \\$file\ | ${SED} -n 's/.*- //p'\`
+ while test -n \\$file\; do
+destdir=\`\$ECHO \X\$file\ | \$Xsed -e 's%/[^/]*\$%%'\`
+
+# If there was a directory component, then change thisdir.
+if test \x\$destdir\ != \x\$file\; then
+ case \\$destdir\ in
+ [/]* | [A-Za-z]:[/]*) thisdir=\\$destdir\ ;;
+ *) thisdir=\\$thisdir/\$destdir\ ;;
+ esac
+fi
+
+file=\`\$ECHO \X\$file\ | \$Xsed -e 's%^.*/%%'\`
+file=\`ls -ld \\$thisdir/\$file\ | ${SED} -n 's/.*- //p'\`
+ done
+
+ # Try to get the absolute directory name.
+ absdir=\`cd \\$thisdir\ pwd\`
+ test -n \\$absdir\ thisdir=\\$absdir\
+
+
+ if test $fast_install = yes; then
+
Re: mdemo ltdl failure
Bob Friesenhahn wrote: On Wed, 18 Apr 2007, Charles Wilson wrote: [snip long description of ugly runtime test] See http://lists.gnu.org/archive/html/libtool-patches/2007-03/msg00030.html After discussion with Bob F, I've reimplemented this fix without the actual runtime test. Instead, if $host_os is cygwin, and cygwin version is 1.5.24 or older, then force use of libltdl builtin argz. In all other cases (including cross), pre-existing detection rules apply. This new version is certainly more attractive than before. Presumably this special case can be safely removed after enough time has elapsed for the majority of Cygwin installs to be updated. Right, give or take a year. 8-P Is the: libmlib_la_LDFLAGS = -no-undefined -export-symbols-regex .* statement portable? (1) Yes (2) and it shouldn't be in this patch anyway. Ralf already applied that bit to HEAD: http://www.mail-archive.com/libtool-patches@gnu.org/msg02848.html My bigger worries with this patch were that it could regress on some other, unrelated platform. I've checked the systems I have access to now, and all seem to do fine. So I have applied the change as below. This is what happens when you try some home-grown version of patch-quilt...long story. -- Chuck
Re: [cygwin, libtool] use shell function to emit wrapper scripts and wrapper.exe source [Was: Re: .exe magic]
Charles Wilson wrote: Okay, here's the first bit. It's pretty simple. Testing is in progress (and in conjuction with the new argz fix I just posted to libtool-patches), but looks good so far: the new wrapper scripts are identical to old ones generated without this patch. Test results -- old tests: == All 115 tests passed (9 tests were not run) --- gcc-3.4.5 doesn't supply gfortran, only g77. == Test results -- new tests. Unexpected failures: 14: Java convenience archives FAILED (convenience.at:273) 16: Link order of deplibs. FAILED (link-order2.at:129) 49: Run tests with low max_cmd_len FAILED (cmdline_wrap.at:42) are actually not unexpected on cygwin. And certainly have nothing to do with this patch. Actually, I think this is may be the best test conformance I've ever seen on cygwin... -- Chuck
