Re: FYI: ksh bug on Tru64 UNIX causes current libtool failure

[Ralf Wildenhues]

Hi Nicolas,

* Nicolas Joly wrote on Tue, Oct 04, 2005 at 03:36:48PM CEST:
> On Tue, Oct 04, 2005 at 12:09:26PM +0200, Ralf Wildenhues wrote:
> > * Nicolas Joly wrote on Mon, Oct 03, 2005 at 05:57:01PM CEST:
> > 
> > > Here follow a small summary for libtool HEAD on my Tru64 v5.1B
> > > workstation.
> > 
> > Could you report `libtool --version', so that, in case of doubt, we know
> > which patches were incorporated and which weren't?
> 
> address@hidden [temp/libtool]> ./libtool --version
> ltmain.sh (GNU libtool 1.2109 2005/10/02 08:54:02) 2.1a
> 
> > If it's before 2005-10-03, I ask you not to update until Gary's BSD make
> > patch is in (so you don't unnecessarily experience a known and pending
> > issue).
> 
> I'm aware of this problem. For now, i'm using GNU make; for Tru64 make
> we'll see later.

You could try 290-gary-pmake-dot-slash-ignorance.diff, I believe it
should work.  But I bet Gary will have applied it before you read this.
:)

> > > * With `lt_ECHO='printf %s\\n'; export lt_ECHO' set, configure
> > >   generate numerous `sed: Function 1s/^X//\n cannot be parsed'
> > >   messages.
> > 
> > Should've been `lt_ECHO='printf %s\n'; export lt_ECHO'
> > Sorry, I believe it was me who posted that wrongly back then.
> 
> I've just restarted with the correct value. configure now pass, but
> make aborts with:
> 
> [...]
> source='libltdl/loaders/preopen.c' 
> object='libltdl/loaders/libltdl_libltdl_la-preopen.lo' libtool=yes \
> DEPDIR=.deps depmode=tru64 /bin/sh ./libltdl/config/depcomp \
> /bin/sh ./libtool --tag=CC   --mode=compile cc -DLTDL -DHAVE_CONFIG_H 
> -DLT_CONFIG_H='<config.h>' -I. -I. -I.  -DLTDLOPEN=libltdl -I. -I. -Ilibltdl 
> -I./libltdl -I./libltdl/libltdl   -g -c -o 
> libltdl/loaders/libltdl_libltdl_la-preopen.lo `test -f 
> 'libltdl/loaders/preopen.c' || echo './'`libltdl/loaders/preopen.c
> ./libtool: bad substitution
> 
> with `set -x', in libtool script:
> 
> [...]
> base_compile= cc -DLTDL -DHAVE_CONFIG_H "-DLT_CONFIG_H=<config.h>" -I. -I. 
> -I. -
> DLTDLOPEN=libltdl -I. -I. -Ilibltdl -I./libltdl -I./libltdl/libltdl -g -c
> + func_stripname -Wc,  -Wc,-MD 
> func_stripname_result=-Wc,-MD
> ./libtool: bad substitution

Ahh.  Please add another `set -x' at the top of func_stripname to see
which of the parameter substitutions fail.

Hmm, the Tru64 shell in POSIX mode documents support for ${foo#bar} and
${foo%bar}.  I bet there's a shell bug lingering when bar is either
double-quoted or bar is another parameter like `${1}'.  Can you play
around a bit to try this?  For example, pdksh fails on
  ${1%$2}
but works if we do
  arg2=$2
  ${1%$arg2}
instead.  Maybe
  arg1=$1
  arg2=$2
  echo ${arg1%$arg2}, ${arg1%"$arg2"}
both work instead?

We should then either fix func_stripname (and a couple of other ones)
to work around this bug or fix _LT_CHECK_XSI_SHELL to expose the bug
(and turn off the fast substitution functions).

> > > libtool: link:  cc -shared -input .libs/libfoo2.so.0.0.0.exp     
> > > .libs/foo2.o   -lm ./.libs/libsub.so -soname libfoo2.so.0 `test -n 
> > > "0.0.0:0.0" && print -r "X-set_version 0.0.0:0.0" | /usr/bin/sed -e 
> > > 1s/^X//` -update_registry .libs/so_locations -o .libs/libfoo2.so.0.0.0
> > > ld:
> > > can't open input file '-soname'(No such file or directory)
> > > ld: Usage: ld [options] file [...]
> > > gmake[4]: *** [libfoo2.la] Error 1
> > > gmake[4]: Leaving directory `/home/njoly/temp/libtool/tests/mdemo'
> > > FAIL: tests/mdemo-make.test
> > 
> > Weird.  The linker seems to need a different option order than given by
> > the compiler driver.  Does it work if you issue this manually?
> > 
> >   cd $top_builddir/tests/mdemo
> >   make          # this should create .libs/libfoo2.so.0.0.0.exp
> >   cc -shared -input .libs/libfoo2.so.0.0.0.exp -soname libfoo2.so.0 `test 
> > -n "0.0.0:0.0" && print -r "X-set_version 0.0.0:0.0" | /usr/bin/sed -e 
> > 1s/^X//` -update_registry .libs/so_locations -o .libs/libfoo2.so.0.0.0 
> > .libs/foo2.o -lm ./.libs/libsub.so 
> 
> No, same result.
> 
> > You can try adding `-v' to see which options' order is messed up.
> > Could you issue the same with the C++ compiler driver `CC' to see
> > whether it has the same bug?
> 
> address@hidden [tests/mdemo]> cc -v -shared -input .libs/libfoo2.so.0.0.0.exp 
> -soname libfoo2.so.0 `test -n "0.0.0:0.0" && print -r "X-set_version 
> 0.0.0:0.0" | /usr/bin/sed -e 1s/^X//` -u pdate_registry .libs/so_locations -o 
> .libs/libfoo2.so.0.0.0 .libs/foo2.o -lm ./.libs/libsub.so 
> 
> /usr/lib/cmplrs/cc.dtk/ld -o .libs/libfoo2.so.0.0.0 -input -soname 
> libfoo2.so.0 -set_version 0.0.0:0.0 -g0 -O1 -shared 
> .libs/libfoo2.so.0.0.0.exp -u pdate_registry .libs/so_locations .libs/foo2.o 
> -lm ./.libs/libsub.so -lc 
> ld:
> can't open input file '-soname'(No such file or directory)
> ld: Usage: ld [options] file [...]
> /usr/lib/cmplrs/cc.dtk/ld: 
> 0.00u 0.00s 0:00 0% 0+0k 0+0io 0pf+0w 0stk+120mem
> 
> According to the Tru64 cc(1) man page, we need to use `-input_to_ld'
> flag instead of `-input' which is only known by the linker. With this
> small modification all previously failed tests are now successful.

Ahh, ok.  Do I gather correctly that the C++ compiler works with
`-input' rather than `-input_to_ld'?

> > If you can make the C part work, you can try adjusting the setting of
> > archive_cmds and archive_expsym_cmds at the top of the libtool script
> > to see if mdemo compiles then.  (The source of this line is in
> > libltdl/m4/libtool.m4, but after changing that you need the autotools
> > again.)
> 
> Patch against libtool.m4 attached.

Thank you very much.  Will apply after the issue above is sorted out.

Could you also try the new test suite?
  make check TESTS=
and send tests/testsuite.log for errors.

Thanks,
Ralf