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

[Ralf Wildenhues]

Hi Nicolas,

I've removed libtool@ from the list of recipients -- no need to discuss
this on both lists.

* Nicolas Joly wrote on Mon, Oct 03, 2005 at 05:57:01PM CEST:
> On Wed, Jul 06, 2005 at 05:08:11AM +0200, Ralf Wildenhues wrote:
> 
> > This is a gentle reminder that this issue with Libtool HEAD/branch-2-0
> > on Tru64 sh is still unsolved.  It'd be nice to get a solution into the
> > next 2.0 release candidate, should such a solution exist.
> 
> Sorry for the delay, i was away and/or busy. :-(

No problem.  Thank you for the feedback!

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

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).

> bootstrap works (very slowly, but it works ...).

Yes, we know about the speed.  :-/

> * Without modification, configure works fine but make abort with
>   `./config.status: print: not found' error message.

Weird.

> * With `BIN_SH=xpg4; export BIN_SH' set before configuring and
>   building both configure and make work. `make check' report 4
>   failures (verbose run attached for the 1st one):
>          FAIL: tests/mdemo-make.test
>          FAIL: tests/mdemo-make.test
>          FAIL: tests/mdemo-dryrun.test
>          FAIL: tests/mdemo-make.test
>   NB: I'm getting the same results with the patch i previoulsy posted,
>   which swap `print -r' and `ksh' tests in _LT_PROG_ECHO_BACKSLASH
>   macro.

This seems to be an unrelated failure, see below.

> * 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.

*snip*
> /bin/sh ./libtool --tag=CC   --mode=link cc  -g -no-undefined -module 
> -export-symbols-regex "libfoo2.*"  -o libfoo2.la -rpath 
> /home/njoly/temp/libtool/_inst/lib foo2.lo -lm libsub.la 
> libtool: link: generating symbol list for `libfoo2.la'
> libtool: link: /usr/bin/nm -B  .libs/foo2.o   | sed -n -e 's/^.*[     
> ]\([BCDEGQRST][BCDEGQRST]*\)[   ][      ]*\([_A-Za-z][_A-Za-z0-9]*\)$/\1 \2 
> \2/p' | /usr/bin/sed 's/.* //' | sort | uniq > .libs/libfoo2.exp
> libtool: link: /usr/bin/grep -E -e "libfoo2.*" ".libs/libfoo2.exp" > 
> ".libs/libfoo2.expT"
> libtool: link: mv -f ".libs/libfoo2.expT" ".libs/libfoo2.exp"
> libtool: link: for i in `cat .libs/libfoo2.exp`; do printf "%s %s\\n" 
> -exported_symbol "/home/njoly/temp/libtool/tests/mdemo/libsub.la" >> 
> .libs/libfoo2.so.0.0.0.exp; done; printf "%s\\n" "-hidden">> 
> .libs/libfoo2.so.0.0.0.exp
> 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 

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?

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.)

In any case, your report indicates that we indeed have fixed the
original issue for which I asked feedback.  :-)

Cheers,
Ralf