Re: ksh bug on Tru64 UNIX causes current libtool failure

2005-06-02 Thread Ralf Wildenhues
Hi Nicolas,

* Nicolas Joly wrote on Thu, Jun 02, 2005 at 01:02:32AM CEST:
 On Wed, May 25, 2005 at 06:22:37PM +0200, Ralf Wildenhues wrote:
  
  OK to apply this patch to branch-2-0 and HEAD, and then backport to
  branch-1-5?
 
 Sorry for the delay.

No problem.  Sorry for not providing a branch-1-5 patch right away.
The backport is straightforward, patch below.

OTOH..

 Unfortunately, i was unable to bootstrap libtool HEAD on my Tru64 unix
 workstation. Next step was to bootstrap it on another machine
 (NetBSD/amd64); back to the Tru64 machine ... another failure.

that just helped us find more HEAD bug(s).  :-/

First, could you post the exact output of `bootstrap' on Tru64?

 The first failure seems to be related to missing `print' command in
 default `/bin/sh':

 [EMAIL PROTECTED] [~] /bin/sh
 $ print -r '\t'
 print: not found
 [EMAIL PROTECTED] [~] BIN_SH=xpg4 /bin/sh
 $ print -r '\t'
 \t

Oh, brother.  How do we solve this?  I suppose
$ /bin/sh
$ BIN_SH=xpg4; export BIN_SH
$ print -r '\t'

does not work, right?  Can we set
  CONFIG_SHELL = BIN_SH=xpg4 /bin/sh
(and also SHELL) in the Makefile?  I can easily spot places where this
breaks in our own Makefile.am, let alone any client Makefile's.

We could have near the top of libtool something like

case $host in
  $whatever_fits_tru64) BIN_SH=xpg4 exec $SHELL ${1+$@} ;;
esac

Alternatively, the better option might be to tweak *DETECT_BETTER_SHELL
to prefer ksh over bin/sh..

 [EMAIL PROTECTED] [~] /bin/ksh
 $ print -r '\t'
 \t

but that sucks too, as it has nontrivial consequences on other systems.
Or maybe search for ksh before testing `print -r'..

By the way, since tru64 seems a rather interesting target for libtool:
If anyone could provide access to such a system, it would be easier to
prevent regressions.

Regards,
Ralf

* ltmain.in (compile mode): In order to find out
about forbidden characters in output, check with grep after checking
func_quote_for_eval result.  Also, warn instead of fail.
(func_infer_tag, compile mode, link mode, install mode):
Revert SunOS sh bug workaround patch from 2004-12-28 as it
triggers bugs in the Tru64 5.1B shell.
Reported by Albert Chin [EMAIL PROTECTED] and
Nicolas Joly [EMAIL PROTECTED].

Index: ltmain.in
===
RCS file: /cvsroot/libtool/libtool/Attic/ltmain.in,v
retrieving revision 1.334.2.70
diff -u -r1.334.2.70 ltmain.in
--- ltmain.in   31 May 2005 03:47:34 -  1.334.2.70
+++ ltmain.in   2 Jun 2005 08:34:11 -
@@ -133,7 +133,6 @@
 execute_dlfiles=
 lo2o=s/\\.lo\$/.${objext}/
 o2lo=s/\\.${objext}\$/.lo/
-quote_scanset='[[~#^*{};?'''   ]'
 
 #
 # Shell function definitions:
@@ -192,7 +191,7 @@
   CC_quoted=
   for arg in $CC; do
case $arg in
- *$quote_scanset* | *]* | *\|* | *\* | *\(* | *\)* | )
+ *[\[\~\#\^\\*\(\)\{\}\|\;\\\?\'\ \ ]*|*]*|)
  arg=\$arg\
  ;;
esac
@@ -213,7 +212,7 @@
for arg in $CC; do
# Double-quote args containing other shell metacharacters.
case $arg in
- *$quote_scanset* | *]* | *\|* | *\* | *\(* | *\)* | )
+ *[\[\~\#\^\\*\(\)\{\}\|\;\\\?\'\ \ ]*|*]*|)
  arg=\$arg\
  ;;
esac
@@ -627,7 +626,7 @@
# Many Bourne shells cannot handle close brackets correctly
# in scan sets, so we specify it separately.
case $arg in
- *$quote_scanset* | *]* | *\|* | *\* | *\(* | *\)* | )
+ *[\[\~\#\^\\*\(\)\{\}\|\;\\\?\'\ \ ]*|*]*|)
  arg=\$arg\
  ;;
esac
@@ -662,7 +661,7 @@
   # in scan sets (worked around with variable expansion),
   # and furthermore cannot handle '|' '' '(' ')' in scan sets 
   # at all, so we specify them separately.
-  *$quote_scanset* | *]* | *\|* | *\* | *\(* | *\)* | )
+  *[\[\~\#\^\\*\(\)\{\}\|\;\\\?\'\ \]*|*]*|)
lastarg=\$lastarg\
;;
   esac
@@ -737,13 +736,12 @@
 
 qlibobj=`$echo X$libobj | $Xsed -e $sed_quote_subst`
 case $qlibobj in
-  *$quote_scanset* | *]* | *\|* | *\* | *\(* | *\)* | )
+  *[\[\~\#\^\\*\(\)\{\}\|\;\\\?\'\ \]*|*]*|)
qlibobj=\$qlibobj\ ;;
 esac
-if test X$libobj != X$qlibobj; then
-   $echo $modename: libobj name \`$libobj' may not contain shell special 
characters.
-   exit $EXIT_FAILURE
-fi
+test X$libobj != X$qlibobj \
+$echo X$libobj | grep '[]~#^*{};?'''  ()|`$[]' \
+$echo $modename: libobj name \`$libobj' may not contain shell 
special characters.
 objname=`$echo X$obj | $Xsed -e 's%^.*/%%'`
 xdir=`$echo X$obj | $Xsed -e 's%/[^/]*$%%'`
 if test X$xdir = X$obj; then
@@ -824,7 +822,7 @@
 fi
 qsrcfile=`$echo X$srcfile | $Xsed -e $sed_quote_subst`
 case $qsrcfile in
-  *$quote_scanset* | *]* | *\|* | 

Re: ksh bug on Tru64 UNIX causes current libtool failure

2005-06-02 Thread Norman Gray


Greetings,

On 2005 Jun 2 , at 10.37, Ralf Wildenhues wrote:


Alternatively, the better option might be to tweak *DETECT_BETTER_SHELL
to prefer ksh over bin/sh..


I don't really want to intervene in this debate, but: wince.  ksh has 
at least the unfortunate property that all file descriptors other than 
0, 1, 2 are closed before an exec, and so aren't inherited by process 
children.  Ksh seems unique in this, though it isn't listed as a 
problem in the autoconf section on shell portability issues.  It's not 
a major problem -- and may not be a problem at all for libtool -- but 
it does make some otherwise attractive idioms impossible.


By the way, since tru64 seems a rather interesting target for 
libtool:


Oooh yes; oh yes indeedy.  I've come to the conclusion that if your 
application builds on Tru64 and OS X, then it'll build just about 
anywhere.


All the best,

Norman


--
--
Norman Gray  :  Physics  Astronomy, Glasgow University, UK
http://www.astro.gla.ac.uk/users/norman/  :  www.starlink.ac.uk





Re: ksh bug on Tru64 UNIX causes current libtool failure

2005-06-01 Thread Nicolas Joly
On Wed, May 25, 2005 at 06:22:37PM +0200, Ralf Wildenhues wrote:
 [ Alexander, the patch to work around shell bugs on your platform breaks
 on other ones.  As the failure on yours are more harmless, I'd like to
 revert them.  See the thread on the libtool mailing list. ]
 
 * Nicolas Joly wrote on Thu, May 19, 2005 at 12:39:43AM CEST:
  On Wed, May 18, 2005 at 11:09:21PM +0200, Ralf Wildenhues wrote:
   * Nicolas Joly wrote on Wed, May 18, 2005 at 05:03:05PM CEST:
   
I can't even compile libtool 1.5.18 on my Tru64 unix V5.1B
workstation:
   *snip*
/bin/ksh ./libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H  -I. -I. 
-I.  -g -c -o ltdl.lo ltdl.c
libtool: compile: libobj name `ltdl.lo' may not contain shell special 
characters.
*** Exit 1
   
   That'll teach me to ever do fatal errors based on shell correctness
   assumptions again.  :(
 
 OK to apply this patch to branch-2-0 and HEAD, and then backport to
 branch-1-5?

Sorry for the delay.

Unfortunately, i was unable to bootstrap libtool HEAD on my Tru64 unix
workstation. Next step was to bootstrap it on another machine
(NetBSD/amd64); back to the Tru64 machine ... another failure.

The first failure seems to be related to missing `print' command in
default `/bin/sh':

[EMAIL PROTECTED] [~] /bin/sh
$ print -r '\t'
print: not found
[EMAIL PROTECTED] [~] BIN_SH=xpg4 /bin/sh
$ print -r '\t'
\t
[EMAIL PROTECTED] [~] /bin/ksh
$ print -r '\t'
\t

gmake[3]: Entering directory `/home/njoly/temp/libtool-2.1a/libltdl'
source='loaders/preopen.c' object='libltdl_la-preopen.lo' libtool=yes \
DEPDIR=.deps depmode=tru64 /bin/sh ../config/depcomp \
/bin/sh ../libtool --tag=CC   --mode=compile cc -DHAVE_CONFIG_H=config.h 
-DLTDL -I. -I. -I..  -DLTDLOPEN=libltdl -I. -I. -I./libltdl   -g -c -o 
libltdl_la-preopen.lo `test -f 'loaders/preopen.c' || echo 
'./'`loaders/preopen.c
../libtool: print: not found
../libtool: print: not found
../libtool: : Permission denied
../libtool: print: not found
sh: /: cannot execute
gmake[3]: *** [libltdl_la-preopen.lo] Error 1

-- 
Nicolas Joly

Biological Software and Databanks.
Institut Pasteur, Paris.




Re: ksh bug on Tru64 UNIX causes current libtool failure

2005-05-25 Thread Ralf Wildenhues
[ Alexander, the patch to work around shell bugs on your platform breaks
on other ones.  As the failure on yours are more harmless, I'd like to
revert them.  See the thread on the libtool mailing list. ]

* Nicolas Joly wrote on Thu, May 19, 2005 at 12:39:43AM CEST:
 On Wed, May 18, 2005 at 11:09:21PM +0200, Ralf Wildenhues wrote:
  * Nicolas Joly wrote on Wed, May 18, 2005 at 05:03:05PM CEST:
  
   I can't even compile libtool 1.5.18 on my Tru64 unix V5.1B
   workstation:
  *snip*
   /bin/ksh ./libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H  -I. -I. 
   -I.  -g -c -o ltdl.lo ltdl.c
   libtool: compile: libobj name `ltdl.lo' may not contain shell special 
   characters.
   *** Exit 1
  
  That'll teach me to ever do fatal errors based on shell correctness
  assumptions again.  :(

OK to apply this patch to branch-2-0 and HEAD, and then backport to
branch-1-5?

BTW, I have been working on actually allowing these special characters
in object file names.  Just not done yet (and that will certainly not be
backported).

Regards,
Ralf

* config/ltmain.m4sh (func_mode_compile): In order to find out
about forbidden characters in output, check with grep after checking
func_quote_for_eval result.  Also, warn instead of fail.
* config/general.m4sh (func_quote_for_eval, func_quote_for_expand):
Revert SunOS sh bug workaround patch from 2004-12-28 as it
triggers bugs in the Tru64 5.1B shell.
Reported by Albert Chin [EMAIL PROTECTED] and
Nicolas Joly [EMAIL PROTECTED].

Index: config/ltmain.m4sh
===
RCS file: /cvsroot/libtool/libtool/config/ltmain.m4sh,v
retrieving revision 1.66
diff -u -r1.66 ltmain.m4sh
--- config/ltmain.m4sh  27 Apr 2005 11:30:38 -  1.66
+++ config/ltmain.m4sh  25 May 2005 16:06:23 -
@@ -1228,7 +1228,8 @@
 
 func_quote_for_eval $libobj
 test X$libobj != X$func_quote_for_eval_result \
-   func_fatal_error libobj name \`$libobj' may not contain shell 
special characters.
+   $ECHO X$libobj | $GREP ['[@:@~#^*{};?'''  ()|`$@:@]'] \
+   func_warning libobj name \`$libobj' may not contain shell special 
characters.
 func_basename $obj
 objname=$func_basename_result
 func_dirname $obj / 
Index: config/general.m4sh
===
RCS file: /cvsroot/libtool/libtool/config/general.m4sh,v
retrieving revision 1.17
diff -u -r1.17 general.m4sh
--- config/general.m4sh 22 Apr 2005 10:10:30 -  1.17
+++ config/general.m4sh 25 May 2005 16:06:23 -
@@ -96,9 +96,6 @@
 # Same as above, but do not quote variable references.
 double_quote_subst='s/\([[`\\]]\)/\\\1/g'
 
-# Protect character class for func_quote_* by variable expansion.
-quote_scanset='[[@:@~#^*{};?'''   ]]'
-
 # Re-`\' parameter expansions in output of double_quote_subst that were
 # `\'-ed in input to the same.  If an odd number of `\' preceded a '$'
 # in input to double_quote_subst, that '$' was protected from expansion.
@@ -286,11 +283,9 @@
   # Double-quote args containing shell metacharacters to delay
   # word splitting, command substitution and and variable
   # expansion for a subsequent eval.
-  # in scan sets, and some SunOS ksh mistreat backslash-escaping
-  # in scan sets (worked around with variable expansion),
-  # and furthermore cannot handle '|' '' '(' ')' in scan sets
-  # at all, so we specify them separately.
-  *$quote_scanset* | *@:@* | *\|* | *\* | *\(* | *\)* | )
+  # Many Bourne shells cannot handle close brackets correctly
+  # in scan sets, so we specify it separately.
+  *[[\@:@\~\#\^\\*\(\)\{\}\|\;\\\?\'\ \]]*|*@:@*|)
 func_quote_for_eval_result=\$func_quote_for_eval_unquoted_result\
 ;;
   *)
@@ -316,11 +311,8 @@
   # Double-quote args containing shell metacharacters to delay
   # word splitting and command substitution for a subsequent eval.
   # Many Bourne shells cannot handle close brackets correctly
-  # in scan sets, and some SunOS ksh mistreat backslash-escaping
-  # in scan sets (worked around with variable expansion),
-  # and furthermore cannot handle '|' '' '(' ')' in scan sets
-  # at all, so we specify them separately.
-  *$quote_scanset* | *@:@* | *\|* | *\* | *\(* | *\)* | )
+  # in scan sets, so we specify it separately.
+  *[[\@:@\~\#\^\\*\(\)\{\}\|\;\\\?\'\ \]]*|*@:@*|)
 my_arg=\$my_arg\
 ;;
 esac