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

[Nicolas Joly]

On Tue, Oct 04, 2005 at 12:09:26PM +0200, Ralf Wildenhues wrote:
> 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?

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.

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

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

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

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.

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

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

Great.

-- 
Nicolas Joly

Biological Software and Databanks.
Institut Pasteur, Paris.

libtool-ccinput.diff
Description: Text document