[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 2>&1; 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 2>&1 && 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 \"\
Re: .exe magic
Hello Charles, all, * Charles Wilson wrote on Wed, Apr 18, 2007 at 08:49:31PM CEST: > [added libtool to CC list] Thanks. > Corinna Vinschen wrote: > > > >Is there any chance that this could be changed in libtool? > > Absolutely. I outlined the steps necessary to do this: > http://cygwin.com/ml/cygwin-apps/2006-03/msg00028.html > > But got not P to TC. Any takers this time around? I'm rather short on time (and not just recently, I know), but ... > 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. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: .exe magic
[added libtool to CC list] Corinna Vinschen wrote: On Apr 18 04:49, Charles Wilson wrote: The current .exe behavior has benefited from many years of tweaking and fine-tuning, across many different packages (cygwin, gcc, gdb, binutils, automake, autoconf, libtool, bash, coreutils, ...) to work together to give the current, mostly coherent, least-surprise behavior we enjoy today. [...] Apart from that, I don't like what libtool does. I think it's a terrible idea to have a script and a binary with the same name (only differing by the .exe suffix) in the same directory. This behaviour breaks the CYGWIN=transparent_exe option and there's no reliable way around this. Is there any chance that this could be changed in libtool? Absolutely. I outlined the steps necessary to do this: http://cygwin.com/ml/cygwin-apps/2006-03/msg00028.html But got not P to TC. Any takers this time around? 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 (or 2.2, or whatever the heck we decide to call it) is released. Of the three steps outlined in the "fix", it's possible that (1) and (2) could go in prior to the 2.0/2.2 release, but this kind of thinking is why we're still in slush and haven't released. -- Chuck P.S. This will make you cry: libtool-1.5.0 was released 14-Apr-2003, four years ago last Saturday. After a year and a half, some destabilizing changes were under consideration and rejected for 2.0 -- we were "too close to a release" -- so an abortive "branch-2-0" was created 3-Oct-2004 and the "destabilizing" changes went into HEAD. Development continued sporadically on this branch for about a year until 24-Aug-2005 -- but throughout, most development effort remained on the trunk or branch-1-5. The load on the developers maintaining three branches was extreme, and branch-2-0 -- supposedly the "almost ready to release" branch -- was getting short shrift, for a YEAR. And the "destabilized" HEAD was now actually *more* stable than branch-2-0! It got so bad that the branch was abandoned, and 2.0 was retargeted to come from cvs HEAD Real Soon Now. Another year and a half, and here we are...still in code slush. (Sounds very very similar to the ongoing discussions with regards to gcc-4.2: http://gcc.gnu.org/ml/gcc/2007-02/msg00427.html and http://gcc.gnu.org/ml/gcc/2007-04/msg00510.html. Only much much worse.) However, there are indications that this situation will come to an end Real Soon Now And This Time We Mean It. So, here's hoping... ___ http://lists.gnu.org/mailman/listinfo/libtool