libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ksh bug on Tru64 UNIX causes current libtool failure


From: Nicolas Joly
Subject: Re: ksh bug on Tru64 UNIX causes current libtool failure
Date: Thu, 2 Jun 2005 21:00:16 +0200
User-agent: Mutt/1.5.8i

On Thu, Jun 02, 2005 at 10:37:27AM +0200, Ralf Wildenhues wrote:
> 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.

Ok, with the patch applied, both libtool-1.5.18 and branch-1-5 are
fine: All 112 tests passed.

> 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?

I must have done something weird; `./boostrap' now works ... and
`./configure' too. But print problems arise with the make command :

gmake[3]: Entering directory `/home/njoly/temp/libtool/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

> > The first failure seems to be related to missing `print' command in
> > default `/bin/sh':
> >
> > address@hidden [~]> /bin/sh
> > $ print -r '\t'
> > print: not found
> > address@hidden [~]> 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?

Yep ... `print: not found'

> 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..
> 
> > address@hidden [~]> /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'..

The latest looks the best one (#1 and #2 are horrible hacks ;-), and
#3 may have serious effects even on non-libtool aware packages).

-- 
Nicolas Joly

Biological Software and Databanks.
Institut Pasteur, Paris.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]