Re: FYI: ksh bug on Tru64 UNIX causes current libtool failure
Hi Nicolas,
To the Fortran part of your answer:
* Nicolas Joly wrote on Wed, Oct 05, 2005 at 03:22:10PM CEST:
On Wed, Oct 05, 2005 at 10:43:40AM +0200, Ralf Wildenhues wrote:
Could you also try the new test suite?
make check TESTS=
and send tests/testsuite.log for errors.
Got 3 failures; log attached.
The first one I can't explain yet (Gary?), the other two are easy:
libtool doesn't support Fortran on Tru64 yet. I'm actually surprised
there aren't more failures, both Fortran-related in the old testsuite,
and non-Fortran related in the new one. :)
For the rest of this mail, I assume this link has suitable(?)
documentation for these Fortran compilers:
http://h21007.www2.hp.com/dspp/files/unprotected/Fortran/docs/unix-um/dfumtoc.htm
data points:
- the doc mentions that undefined symbols are not allowed -- but ld(1)
says otherwise. Maybe it works with
allow_undefined_flag=\${wl}-expect_unresolved \${wl}\*
or, if it doesn't, we need to set
allow_undefined_flag=unsupported
- all of `-soname ..', `-msym', `-set_version ..', `-update_registry ..'
seem unsupported by f77/f95, but I believe they should be supplied to
ld by prefixing ${wl} everywhere -- not really sure, though.
This suggests that it should be possible to write archive_cmds (and
possibly archive_expsyms_cmds) in libltdl/m4/libtool.m4:_LT_LINKER_SHLIBS
like a mixture of the $GCC and the non-$GCC case, using $cc_basename and
$GCC as decision criteria. Would you be willing to work on this?
Should I create a preliminary patch you could test? Is there also a
`f90' available on this platform?
uname -m = alpha
uname -r = V5.1
uname -s = OSF1
uname -v = 2650
Failed tests:
libtool 2.1a test suite test groups:
NUM: FILE-NAME:LINE TEST-GROUP-NAME
KEYWORDS
4: libtoolize.at:287 copy ltdl.m4 with shared macro directory
9: convenience.at:74 F77 convenience archives
F77
10: convenience.at:116 FC convenience archives
FC
# -*- compilation -*-
9. convenience.at:74: testing ...
./convenience.at:75: test -n $F77 || (exit 77)
libtool: link: creating libb.la
libtool: link: ( cd .libs rm -f libb.la ln -s ../libb.la
libb.la )
libtool: link: (cd .libs/libcee.lax/liba.a ar x
/home/njoly/temp/libtool/tests/testsuite.dir/9/./.libs/liba.a)
libtool: link: (cd .libs/libcee.lax/libb.a ar x
/home/njoly/temp/libtool/tests/testsuite.dir/9/./.libs/libb.a)
libtool: link: f77 -shared -expect_unresolved \* .libs/c.o
.libs/libcee.lax/liba.a/a.o .libs/libcee.lax/libb.a/b.o-msym -soname
libcee.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/libcee.so.0.0.0
f77: Severe: Invalid file name - must be of the form name.suffix : *
./convenience.at:108: $LIBTOOL --tag=F77 --mode=link $F77 $FFLAGS $LDFLAGS
-static -o main_static main.lo libcee.la
stderr:
libtool: link: cannot find the library `libcee.la' or unhandled argument
`libcee.la'
stdout:
./convenience.at:108: exit code was 1, expected 0
9. convenience.at:74: 9. F77 convenience archives (convenience.at:74): FAILED
(convenience.at:108)
# -*- compilation -*-
10. convenience.at:116: testing ...
./convenience.at:117: test -n $FC || (exit 77)
libtool: compile: f95 -c -g a.f -o .libs/a.o
libtool: compile: f95 -c -g a.f -o a.o /dev/null 21
libtool: compile: f95 -c -g b.f -o .libs/b.o
libtool: compile: f95 -c -g b.f -o b.o /dev/null 21
libtool: compile: f95 -c -g c.f -o .libs/c.o
libtool: compile: f95 -c -g c.f -o c.o /dev/null 21
libtool: compile: f95 -c -g main.f -o .libs/main.o
libtool: compile: f95 -c -g main.f -o main.o /dev/null 21
libtool: link: ar cru .libs/liba.a .libs/a.o
libtool: link: ranlib .libs/liba.a
libtool: link: creating liba.la
libtool: link: ( cd .libs rm -f liba.la ln -s ../liba.la
liba.la )
libtool: link: ar cru .libs/libb.a .libs/b.o
libtool: link: ranlib .libs/libb.a
libtool: link: creating libb.la
libtool: link: ( cd .libs rm -f libb.la ln -s ../libb.la
libb.la )
libtool: link: (cd .libs/libcee.lax/liba.a ar x
/home/njoly/temp/libtool/tests/testsuite.dir/10/./.libs/liba.a)
libtool: link: (cd .libs/libcee.lax/libb.a ar x
/home/njoly/temp/libtool/tests/testsuite.dir/10/./.libs/libb.a)
libtool: link: f95 -shared -expect_unresolved \* .libs/c.o
.libs/libcee.lax/liba.a/a.o .libs/libcee.lax/libb.a/b.o-msym -soname
libcee.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/libcee.so.0.0.0
f95: Severe: Invalid file name - must be of the form name.suffix : *
./convenience.at:150: $LIBTOOL --tag=FC --mode=link $FC $FCFLAGS $LDFLAGS
-static -o main_static main.lo libcee.la
stderr:
libtool: link: cannot find the library `libcee.la' or unhandled argument
`libcee.la'
stdout:
./convenience.at:150: exit
Re: FYI: ksh bug on Tru64 UNIX causes current libtool failure
On Thu, Oct 06, 2005 at 02:27:26PM +0200, Ralf Wildenhues wrote:
Hi Nicolas,
To the Fortran part of your answer:
* Nicolas Joly wrote on Wed, Oct 05, 2005 at 03:22:10PM CEST:
On Wed, Oct 05, 2005 at 10:43:40AM +0200, Ralf Wildenhues wrote:
Could you also try the new test suite?
make check TESTS=
and send tests/testsuite.log for errors.
Got 3 failures; log attached.
The first one I can't explain yet (Gary?)
Don;t worry to much about it. I updated CVS libtool in the mean time,
and this one is gone.
the other two are easy:
libtool doesn't support Fortran on Tru64 yet. I'm actually surprised
there aren't more failures, both Fortran-related in the old testsuite,
and non-Fortran related in the new one. :)
For the rest of this mail, I assume this link has suitable(?)
documentation for these Fortran compilers:
http://h21007.www2.hp.com/dspp/files/unprotected/Fortran/docs/unix-um/dfumtoc.htm
data points:
- the doc mentions that undefined symbols are not allowed -- but ld(1)
says otherwise. Maybe it works with
allow_undefined_flag=\${wl}-expect_unresolved \${wl}\*
or, if it doesn't, we need to set
allow_undefined_flag=unsupported
- all of `-soname ..', `-msym', `-set_version ..', `-update_registry ..'
seem unsupported by f77/f95, but I believe they should be supplied to
ld by prefixing ${wl} everywhere -- not really sure, though.
It seems correct.
Tru64 fortran compilers do not support `-expect_unresolved \*' option
directly. Passing it prefixed with `-Wl,' solves the problem.
All others seems to work directly :
[EMAIL PROTECTED] [testsuite.dir/9] f77 -v -shared -Wl,-expect_unresolved
-Wl,\* .libs/c.o .libs/libcee.lax/liba.a/a.o .libs/libcee.lax/libb.a/b.o -msym
-soname libcee.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/libcee.so.0.0.0
/usr/bin/cc -v -shared -Wl,-expect_unresolved -Wl,* .libs/c.o
.libs/libcee.lax/liba.a/a.o .libs/libcee.lax/libb.a/b.o -msym -soname
libcee.so.0 -set_version 0.0.0:0.0 -update_registry .libs/so_locations -o
.libs/libcee.so.0.0.0 -O4 -qlshpf -lUfor -lfor -lFutil -lm -lots -lm_c32 -lmld
-lexc
/usr/lib/cmplrs/cc.dtk/ld -o .libs/libcee.so.0.0.0 -expect_unresolved * -msym
-soname libcee.so.0 -set_version 0.0.0:0.0 -update_registry .libs/so_locations
-g0 -O4 -shared .libs/c.o .libs/libcee.lax/liba.a/a.o
.libs/libcee.lax/libb.a/b.o -qlshpf -lUfor -lfor -lFutil -lm -lots -lm_c32
-lmld -lexc -lc
/usr/lib/cmplrs/cc.dtk/ld:
0.03u 0.03s 0:00 35% 0+10k 11+21io 0pf+0w 10stk+1800mem
This suggests that it should be possible to write archive_cmds (and
possibly archive_expsyms_cmds) in libltdl/m4/libtool.m4:_LT_LINKER_SHLIBS
like a mixture of the $GCC and the non-$GCC case, using $cc_basename and
$GCC as decision criteria. Would you be willing to work on this?
I'll try, even if i'm not a fortran programmer myself.
Should I create a preliminary patch you could test?
Yes, please.
Is there also a `f90' available on this platform?
f90 - invokes the Compaq Fortran 90 (formerly DIGITAL Fortran 90) compiler
f95 - invokes the Compaq Fortran 95 (formerly DIGITAL Fortran 95) compiler
f77 - invokes the Compaq Fortran 90 (formerly DIGITAL Fortran 90) compiler
f77 -old_f77 - invokes the Compaq Fortran 77 (formerly DIGITAL Fortran 77)
compiler
uname -m = alpha
uname -r = V5.1
uname -s = OSF1
uname -v = 2650
Failed tests:
libtool 2.1a test suite test groups:
NUM: FILE-NAME:LINE TEST-GROUP-NAME
KEYWORDS
4: libtoolize.at:287 copy ltdl.m4 with shared macro directory
9: convenience.at:74 F77 convenience archives
F77
10: convenience.at:116 FC convenience archives
FC
# -*- compilation -*-
9. convenience.at:74: testing ...
./convenience.at:75: test -n $F77 || (exit 77)
libtool: link: creating libb.la
libtool: link: ( cd .libs rm -f libb.la ln -s ../libb.la
libb.la )
libtool: link: (cd .libs/libcee.lax/liba.a ar x
/home/njoly/temp/libtool/tests/testsuite.dir/9/./.libs/liba.a)
libtool: link: (cd .libs/libcee.lax/libb.a ar x
/home/njoly/temp/libtool/tests/testsuite.dir/9/./.libs/libb.a)
libtool: link: f77 -shared -expect_unresolved \* .libs/c.o
.libs/libcee.lax/liba.a/a.o .libs/libcee.lax/libb.a/b.o-msym
-soname libcee.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/libcee.so.0.0.0
f77: Severe: Invalid file name - must be of the form name.suffix : *
./convenience.at:108: $LIBTOOL --tag=F77 --mode=link $F77 $FFLAGS $LDFLAGS
-static -o main_static main.lo libcee.la
stderr:
libtool: link: cannot find the library `libcee.la' or unhandled argument
`libcee.la'
stdout:
./convenience.at:108: exit code was 1, expected 0
9. convenience.at:74: 9. F77 convenience archives
Re: FYI: ksh bug on Tru64 UNIX causes current libtool failure
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?
[EMAIL PROTECTED] [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?
[EMAIL PROTECTED] [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
Re: FYI: ksh bug on Tru64 UNIX causes current libtool failure
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? [EMAIL PROTECTED] [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
Re: FYI: ksh bug on Tru64 UNIX causes current libtool failure
On Wed, Jul 06, 2005 at 05:08:11AM +0200, Ralf Wildenhues wrote: Hi Nicolas, others, Hi Ralf, 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. :-( Here follow a small summary for libtool HEAD on my Tru64 v5.1B workstation. bootstrap works (very slowly, but it works ...). * Without modification, configure works fine but make abort with `./config.status: print: not found' error message. * 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. * With `lt_ECHO='printf %s\\n'; export lt_ECHO' set, configure generate numerous `sed: Function 1s/^X//\n cannot be parsed' messages. Regards. -- Nicolas Joly Biological Software and Databanks. Institut Pasteur, Paris. gmake check-recursive gmake[1]: Entering directory `/home/njoly/temp/libtool' gmake[2]: Entering directory `/home/njoly/temp/libtool' gmake check-TESTS check-local gmake[3]: Entering directory `/home/njoly/temp/libtool' mdemo-static.test: === Running mdemo-static.test mdemo-static.test: === Running `gmake distclean' in mdemo gmake[4]: Entering directory `/home/njoly/temp/libtool/tests/mdemo' rm -f mdemo mdemo rm -f mdemo_static mdemo_static test -z libsub.la foo1.la libfoo2.la libmlib.la || rm -f libsub.la foo1.la libfoo2.la libmlib.la rm -f ./so_locations rm -f ./so_locations rm -f ./so_locations rm -f ./so_locations rm -rf .libs _libs rm -f *.o rm -f *.lo rm -f *.tab.c test -z || rm -f rm -f libtool rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags rm -f config.status config.cache config.log configure.lineno configure.status.lineno rm -f Makefile gmake[4]: Leaving directory `/home/njoly/temp/libtool/tests/mdemo' mdemo-static.test: === Configuring in mdemo mdemo-static.test: === /bin/sh /home/njoly/temp/libtool/tests/mdemo/configure --srcdir=/home/njoly/temp/libtool/tests/mdemo --prefix=/home/njoly/temp/libtool/_inst checking for a BSD-compatible install... ../../libltdl/config/install-sh -c checking whether build environment is sane... yes checking for gawk... no checking for mawk... no checking for nawk... nawk checking whether gmake sets $(MAKE)... yes checking for gcc... cc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... no checking whether cc accepts -g... yes checking for cc option to accept ISO C89... none needed checking for style of include used by gmake... GNU checking dependency style of cc... tru64 checking for an ANSI C-conforming const... yes checking build system type... alphaev56-dec-osf5.1b checking host system type... alphaev56-dec-osf5.1b checking for a sed that does not truncate output... /usr/bin/sed checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for fgrep... /usr/bin/grep -F checking for non-GNU ld... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... no checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B checking the name lister (/usr/bin/nm -B) interface... BSD nm checking whether ln -s works... yes checking the maximum length of command line arguments... 16384 checking whether the shell understands some XSI constructs... yes checking for /usr/bin/ld option to reload object files... -r checking how to recognise dependent libraries... pass_all checking for ar... ar checking for strip... strip checking for ranlib... ranlib checking command to parse /usr/bin/nm -B output from cc object... ok checking how to run the C preprocessor... cc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for dlfcn.h... yes checking for shl_load... no checking for shl_load in -ldld... no checking for dlopen... yes checking whether a program can dlopen itself... yes checking whether a statically linked program can dlopen itself... yes checking for objdir... .libs checking for cc option to produce PIC... -DPIC checking if cc PIC flag -DPIC works... yes checking if cc static flag -non_shared works... yes checking if cc
Re: FYI: ksh bug on Tru64 UNIX causes current libtool failure
On Sun, Jul 10, 2005 at 11:34:13AM +0900, Peter O'Gorman wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Albert Chin wrote: |05:00 PM dogbert ~$PS1='$ ' /bin/sh |$ echo Xbla | sed 1s,^X,, |X,,: not found |$ sed: Function 1s, cannot be parsed. | | | What system is this? Works fine on 4.0D and 5.1. | I don't think you tried /bin/sh. Works okay with zsh or even with /usr/bin/posix/sh though. Ah, you're right. /usr/bin/posix/sh == /bin/ksh. -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: FYI: ksh bug on Tru64 UNIX causes current libtool failure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Albert Chin wrote: |05:00 PM dogbert ~$PS1='$ ' /bin/sh |$ echo Xbla | sed 1s,^X,, |X,,: not found |$ sed: Function 1s, cannot be parsed. | | | What system is this? Works fine on 4.0D and 5.1. | I don't think you tried /bin/sh. Works okay with zsh or even with /usr/bin/posix/sh though. Peter -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Darwin) iQCVAwUBQtCJJbiDAg3OZTLPAQLV4AQAocdPaECwoB261oWvd44dJhmQ2X4SMpzY lWAH1Rj+Dzt9CrFEsdqPWTMzQr1SZKHWp7Wiie1or32bCaiOYGmBmQT8tpPBKG5t sB7arPqY9IIMLU9S42t6JJ1P4V7n5kqXfkrrNT7n0A85Wldmr7KkB5mXD6nE/wk3 f280fAEb9Z0= =SReQ -END PGP SIGNATURE- ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: FYI: ksh bug on Tru64 UNIX causes current libtool failure
On Thu, Jul 07, 2005 at 05:02:26PM -0500, Tim Mooney wrote: In regard to: Re: FYI: ksh bug on Tru64 UNIX causes current libtool...: * Ralf Wildenhues wrote on Wed, Jul 06, 2005 at 05:08:11AM CEST: 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. Stupid question: Does Tru64 sh need `^' quoted? The one Solaris one does. I.e., does echo Xbla | sed 1s,^X,, work there? (Libtool currently does not quote this consistently.) I haven't seen any responses to this, so I will: it does need it quoted: 05:00 PM dogbert ~$PS1='$ ' /bin/sh $ echo Xbla | sed 1s,^X,, X,,: not found $ sed: Function 1s, cannot be parsed. What system is this? Works fine on 4.0D and 5.1. -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: FYI: ksh bug on Tru64 UNIX causes current libtool failure
In regard to: Re: FYI: ksh bug on Tru64 UNIX causes current libtool...: * Ralf Wildenhues wrote on Wed, Jul 06, 2005 at 05:08:11AM CEST: 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. Stupid question: Does Tru64 sh need `^' quoted? The one Solaris one does. I.e., does echo Xbla | sed 1s,^X,, work there? (Libtool currently does not quote this consistently.) I haven't seen any responses to this, so I will: it does need it quoted: 05:00 PM dogbert ~$PS1='$ ' /bin/sh $ echo Xbla | sed 1s,^X,, X,,: not found $ sed: Function 1s, cannot be parsed. $ exit Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: FYI: ksh bug on Tru64 UNIX causes current libtool failure
* Ralf Wildenhues wrote on Wed, Jul 06, 2005 at 05:08:11AM CEST: 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. Stupid question: Does Tru64 sh need `^' quoted? The one Solaris one does. I.e., does echo Xbla | sed 1s,^X,, work there? (Libtool currently does not quote this consistently.) Regards, Ralf
Re: FYI: ksh bug on Tru64 UNIX causes current libtool failure
* Ralf Wildenhues wrote on Wed, Jul 06, 2005 at 05:08:11AM CEST: 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. Stupid question: Does Tru64 sh need `^' quoted? The one Solaris one does. I.e., does echo Xbla | sed 1s,^X,, work there? (Libtool currently does not quote this consistently.) Regards, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: FYI: ksh bug on Tru64 UNIX causes current libtool failure
On Sun, Jun 05, 2005 at 07:38:59PM +0200, Ralf Wildenhues wrote: * Nicolas Joly wrote on Thu, Jun 02, 2005 at 09:00:16PM CEST: On Thu, Jun 02, 2005 at 10:37:27AM +0200, Ralf Wildenhues wrote: * 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? Ok, with the patch applied, both libtool-1.5.18 and branch-1-5 are fine: All 112 tests passed. Applied the first patch below to HEAD, branch-2-0, the second to branch-1-5. Thanks a lot. 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 : Since this is not fixed yet, here's at least a workaround: specify either one (or both) of CONFIG_SHELL and ECHO resp. lt_ECHO (branch-1-5 resp. branch-2-0/HEAD) while configuring. CONFIG_SHELL needs to be done like so: CONFIG_SHELL=/bin/foosh /bin/foosh path/to/configure [OPTIONS..] and you should provide an echo which does not interpret backslashes (one of `echo', `/bin/echo', `print -r', `printf %s\\n' should usually do). In the mean time, i tested the solution where `print -r' and `ksh' tests are swapped (attached patch). It seems to go a little further (no more `print' error messages), but seems to fail in another ksh problem/bug : [...] libtool: compile: cc -DHAVE_CONFIG_H=config.h -DLTDL -I. -I. -I.. -I. -I. -I./libltdl -g -c -MD loaders/dlopen.c -o dlopen.o /dev/null 21 /bin/ksh ../libtool --tag=CC --mode=link cc -g -module -avoid-version -o dlopen.la dlopen.lo ../libtool[24]: invalid multibyte character ../libtool[6]: invalid multibyte character ../libtool[2312]: invalid multibyte character libtool: link: invalid operation mode `link' libtool: link: Try `libtool --help --mode=link' for more information. ../libtool[7679]: invalid multibyte character ../libtool[7679]: invalid multibyte character ../libtool[7679]: invalid multibyte character [...] ../libtool[7679]: invalid multibyte character ../libtool[7679]: invalid multibyte character gmake[3]: *** [dlopen.la] Segmentation fault gmake[3]: Leaving directory `/home/njoly/temp/libtool/libltdl' gmake[2]: *** [all] Error 2 -- Nicolas Joly Biological Software and Databanks. Institut Pasteur, Paris. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: FYI: ksh bug on Tru64 UNIX causes current libtool failure
* Nicolas Joly wrote on Tue, Jun 07, 2005 at 12:10:47PM CEST: On Sun, Jun 05, 2005 at 07:38:59PM +0200, Ralf Wildenhues wrote: CONFIG_SHELL=/bin/foosh /bin/foosh path/to/configure [OPTIONS..] and you should provide an echo which does not interpret backslashes (one of `echo', `/bin/echo', `print -r', `printf %s\\n' should usually do). In the mean time, i tested the solution where `print -r' and `ksh' tests are swapped (attached patch). It seems to go a little further (no more `print' error messages), but seems to fail in another ksh problem/bug : Please rerun the libtool command line with --debug and post output, you may pack (gzip, bzip2). Regards, Ralf [...] libtool: compile: cc -DHAVE_CONFIG_H=config.h -DLTDL -I. -I. -I.. -I. -I. -I./libltdl -g -c -MD loaders/dlopen.c -o dlopen.o /dev/null 21 /bin/ksh ../libtool --tag=CC --mode=link cc -g -module -avoid-version -o dlopen.la dlopen.lo ../libtool[24]: invalid multibyte character ../libtool[6]: invalid multibyte character ../libtool[2312]: invalid multibyte character libtool: link: invalid operation mode `link' libtool: link: Try `libtool --help --mode=link' for more information. ../libtool[7679]: invalid multibyte character ../libtool[7679]: invalid multibyte character ../libtool[7679]: invalid multibyte character [...] ../libtool[7679]: invalid multibyte character ../libtool[7679]: invalid multibyte character gmake[3]: *** [dlopen.la] Segmentation fault gmake[3]: Leaving directory `/home/njoly/temp/libtool/libltdl' gmake[2]: *** [all] Error 2 ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: FYI: ksh bug on Tru64 UNIX causes current libtool failure
On Tue, Jun 07, 2005 at 12:35:00PM +0200, Ralf Wildenhues wrote:
* Nicolas Joly wrote on Tue, Jun 07, 2005 at 12:10:47PM CEST:
On Sun, Jun 05, 2005 at 07:38:59PM +0200, Ralf Wildenhues wrote:
CONFIG_SHELL=/bin/foosh /bin/foosh path/to/configure [OPTIONS..]
and you should provide an echo which does not interpret backslashes
(one of `echo', `/bin/echo', `print -r', `printf %s\\n' should usually
do).
In the mean time, i tested the solution where `print -r' and `ksh'
tests are swapped (attached patch). It seems to go a little further
(no more `print' error messages), but seems to fail in another ksh
problem/bug :
Please rerun the libtool command line with --debug and post output,
you may pack (gzip, bzip2).
libtool.dbg.bz2 attached.
Regards.
NB: Attached the patch forgotten in previous email too :-(
--
Nicolas Joly
Biological Software and Databanks.
Institut Pasteur, Paris.
libtool.dbg.bz2
Description: Binary data
Index: m4/libtool.m4
===
RCS file: /cvsroot/libtool/libtool/m4/libtool.m4,v
retrieving revision 1.194
diff -u -r1.194 libtool.m4
--- m4/libtool.m4 6 Jun 2005 16:12:53 - 1.194
+++ m4/libtool.m4 7 Jun 2005 09:41:26 -
@@ -818,19 +818,19 @@
if test X$ECHO = Xecho; then
# We didn't find a better echo, so look for alternatives.
- if test X`{ print -r '\t'; } 2/dev/null` = 'X\t'
- echo_testing_string=`{ print -r $echo_test_string; } 2/dev/null`
- test X$echo_testing_string = X$echo_test_string; then
-# This shell has a builtin print -r that does the trick.
-ECHO='print -r'
- elif { test -f /bin/ksh || test -f /bin/ksh$ac_exeext; }
- test X$CONFIG_SHELL != X/bin/ksh; then
+ if { test -f /bin/ksh || test -f /bin/ksh$ac_exeext; }
+ test X$CONFIG_SHELL != X/bin/ksh; then
# If we have ksh, try running configure again with it.
ORIGINAL_CONFIG_SHELL=${CONFIG_SHELL-/bin/sh}
export ORIGINAL_CONFIG_SHELL
CONFIG_SHELL=/bin/ksh
export CONFIG_SHELL
exec $CONFIG_SHELL [$]0 --no-reexec ${1+[$]@}
+ elif test X`{ print -r '\t'; } 2/dev/null` = 'X\t'
+ echo_testing_string=`{ print -r $echo_test_string; } 2/dev/null`
+ test X$echo_testing_string = X$echo_test_string; then
+# This shell has a builtin print -r that does the trick.
+ECHO='print -r'
else
# Try using printf.
ECHO='printf %s\n'
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: FYI: ksh bug on Tru64 UNIX causes current libtool failure
* Nicolas Joly wrote on Tue, Jun 07, 2005 at 01:27:25PM CEST: On Tue, Jun 07, 2005 at 12:35:00PM +0200, Ralf Wildenhues wrote: * Nicolas Joly wrote on Tue, Jun 07, 2005 at 12:10:47PM CEST: In the mean time, i tested the solution where `print -r' and `ksh' tests are swapped (attached patch). It seems to go a little further (no more `print' error messages), but seems to fail in another ksh problem/bug : [ which ends in a segmentation fault. ] Please rerun the libtool command line with --debug and post output, you may pack (gzip, bzip2). libtool.dbg.bz2 attached. OK, let's cut this testing a little short. It seems that Tru64 fails to provide any decent kind of shell for its users. I consider just putting a note about Tru64 into README (branch-1-5) resp. doc/notes.texi (HEAD). Proposal would be one of the following (whichever works and passes the test suite): | Note that Tru64 V5.1B ksh has some bugs which make it hardly useable for | libtoolized packages. Please set | BIN_SH=xpg4; export BIN_SH | in your environment for configuring and building. | Note that Tru64 V5.1B ksh has some bugs which make it hardly useable for | libtoolized packages. Please set | lt_ECHO='printf %s\\n'; export lt_ECHO | in your environment for configuring and building. (s/lt_ECHO/ECHO/g for branch-1-5). What do you think? Which one? Could one of the Tru64 users be bothered to send a bug report to HP? Regards, and thanks for all your testing, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: FYI: ksh bug on Tru64 UNIX causes current libtool failure
On Tue, Jun 07, 2005 at 03:31:22PM +0200, Ralf Wildenhues wrote: * Nicolas Joly wrote on Tue, Jun 07, 2005 at 01:27:25PM CEST: On Tue, Jun 07, 2005 at 12:35:00PM +0200, Ralf Wildenhues wrote: * Nicolas Joly wrote on Tue, Jun 07, 2005 at 12:10:47PM CEST: In the mean time, i tested the solution where `print -r' and `ksh' tests are swapped (attached patch). It seems to go a little further (no more `print' error messages), but seems to fail in another ksh problem/bug : [ which ends in a segmentation fault. ] Please rerun the libtool command line with --debug and post output, you may pack (gzip, bzip2). libtool.dbg.bz2 attached. OK, let's cut this testing a little short. It seems that Tru64 fails to provide any decent kind of shell for its users. I consider just putting a note about Tru64 into README (branch-1-5) resp. doc/notes.texi (HEAD). Proposal would be one of the following (whichever works and passes the test suite): | Note that Tru64 V5.1B ksh has some bugs which make it hardly useable for | libtoolized packages. Please set | BIN_SH=xpg4; export BIN_SH | in your environment for configuring and building. This one does not work ... It will solve the `print' problem, but will lead to the shell crash a little later. with `BIN_SH=xpg4' set, `/usr/bin/posix/sh' is executed instead of the classic `/bin/sh'; and, unfortunately, this is a hard link to `ksh'. [EMAIL PROTECTED] [~] ls -ldi /usr/bin/posix/sh /usr/bin/ksh 482 -rwxr-xr-x 2 bin bin 307248 Oct 16 2002 /usr/bin/ksh 482 -rwxr-xr-x 2 bin bin 307248 Oct 16 2002 /usr/bin/posix/sh | Note that Tru64 V5.1B ksh has some bugs which make it hardly useable for | libtoolized packages. Please set | lt_ECHO='printf %s\\n'; export lt_ECHO | in your environment for configuring and building. (s/lt_ECHO/ECHO/g for branch-1-5). Will test, and report. What do you think? Which one? Could one of the Tru64 users be bothered to send a bug report to HP? Sorry i can't. Our sysadmins tried to have a software support contract from Digital/Compaq for many years, but didn't get any succes ! They give up when HP came up ... -- Nicolas Joly Biological Software and Databanks. Institut Pasteur, Paris. ___ http://lists.gnu.org/mailman/listinfo/libtool
