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