Re: FYI: ksh bug on Tru64 UNIX causes current libtool failure
On Wed, Oct 05, 2005 at 03:22:10PM +0200, Nicolas Joly wrote:
> On Wed, Oct 05, 2005 at 10:43:40AM +0200, Ralf Wildenhues wrote:
> > 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:
> > > >
> > > > 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='' -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=" -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).
>
> Will try to have a look and report.
This one is not a real problem, BIN_SH was not set and the shell was
not in POSIX mode ... normal failure.
With all my experiments, i think we need to have `BIN_SH=xpg4'
automatically defined to proceed with libtool on Tru64.
--
Nicolas Joly
Biological Software and Databanks.
Institut Pasteur, Paris.
Re: Tru64 Fortran compiler support (was: FYI: ksh bug on Tru64 UNIX causes current libtool failure)
On Thu, Oct 06, 2005 at 06:27:32PM +0200, Ralf Wildenhues wrote:
> Hi Nicolas,
>
> * Nicolas Joly wrote on Thu, Oct 06, 2005 at 03:00:51PM CEST:
> > On Thu, Oct 06, 2005 at 02:27:26PM +0200, Ralf Wildenhues wrote:
> > > * Nicolas Joly wrote on Wed, Oct 05, 2005 at 03:22:10PM CEST:
> > > >
> > > > Got 3 failures; log attached.
[...]
> > > 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.
>
> See below. If all the C compiler does is pass `-expect_unresolved pattern'
> through to the linker anyway, we could also just skip the `case' thingy
> and add the `${wl}' every time..
I just checked that both `-expect_unresolved \*' and
`-Wl,-expect_unresolved -Wl,\*' give the same ld(1) command line.
With your patch the 2 fortran tests now pass :
9: F77 convenience archives ok
10: FC convenience archives ok
And the testsuite looks good :
29 tests behaved as expected.
1 test was skipped.
To summarize, libtool HEAD now works on Tru64 with `BIN_SH=xpg4' set
in the environement.
--
Nicolas Joly
Biological Software and Databanks.
Institut Pasteur, Paris.
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/l
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='' -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=" -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'
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 ob
Re: FYI: ksh bug on Tru64 UNIX causes current libtool failure
On Wed, Jul 06, 2005 at 03:44:07PM -0500, Albert Chin wrote: > On Wed, Jul 06, 2005 at 09:46:31PM +0200, Ralf Wildenhues wrote: > > * 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.) > > On Tru64 UNIX 4.0D and 5.1: > # /bin/ksh > # echo Xbla | sed 1s,^X,, > bla Same on my Tru64 5.1B workstation. -- Nicolas Joly Biological Software and Databanks. Institut Pasteur, Paris.
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.
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'
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=" -DLTDL -I. -I. -I.. -I. -I. -I./libltdl -g -c -MD loaders/dlopen.c -o dlopen.o >/dev/null 2>&1 /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.
Re: ksh bug on Tru64 UNIX causes current libtool failure
On Thu, Jun 02, 2005 at 10:37:27AM +0200, Ralf Wildenhues wrote:
> Hi Nicolas,
>
> * 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?
> >
> > Sorry for the delay.
>
> No problem. Sorry for not providing a branch-1-5 patch right away.
> The backport is straightforward, patch below.
Ok, with the patch applied, both libtool-1.5.18 and branch-1-5 are
fine: All 112 tests passed.
> OTOH..
>
> > 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 :
gmake[3]: Entering directory `/home/njoly/temp/libtool/libltdl'
source='loaders/preopen.c' object='libltdl_la-preopen.lo' libtool=yes \
DEPDIR=.deps depmode=tru64 /bin/sh ../config/depcomp \
/bin/sh ../libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H=""
-DLTDL -I. -I. -I.. -DLTDLOPEN=libltdl -I. -I. -I./libltdl -g -c -o
libltdl_la-preopen.lo `test -f 'loaders/preopen.c' || echo
'./'`loaders/preopen.c
../libtool: print: not found
../libtool: print: not found
../libtool: : Permission denied
../libtool: print: not found
sh: /: cannot execute
gmake[3]: *** [libltdl_la-preopen.lo] Error 1
> > The first failure seems to be related to missing `print' command in
> > default `/bin/sh':
> >
> > [EMAIL PROTECTED] [~]> /bin/sh
> > $ print -r '\t'
> > print: not found
> > [EMAIL PROTECTED] [~]> BIN_SH=xpg4 /bin/sh
> > $ print -r '\t'
> > \t
>
> Oh, brother. How do we solve this? I suppose
> $ /bin/sh
> $ BIN_SH=xpg4; export BIN_SH
> $ print -r '\t'
>
> does not work, right?
Yep ... `print: not found'
> Can we set
> CONFIG_SHELL = BIN_SH=xpg4 /bin/sh
> (and also SHELL) in the Makefile? I can easily spot places where this
> breaks in our own Makefile.am, let alone any client Makefile's.
>
> We could have near the top of libtool something like
>
> case $host in
> $whatever_fits_tru64) BIN_SH=xpg4 exec $SHELL ${1+"$@"} ;;
> esac
>
> Alternatively, the better option might be to tweak *DETECT_BETTER_SHELL
> to prefer ksh over bin/sh..
>
> > [EMAIL PROTECTED] [~]> /bin/ksh
> > $ print -r '\t'
> > \t
>
> but that sucks too, as it has nontrivial consequences on other systems.
> Or maybe search for ksh before testing `print -r'..
The latest looks the best one (#1 and #2 are horrible hacks ;-), and
#3 may have serious effects even on non-libtool aware packages).
--
Nicolas Joly
Biological Software and Databanks.
Institut Pasteur, Paris.
Re: ksh bug on Tru64 UNIX causes current libtool failure
On Wed, May 25, 2005 at 06:22:37PM +0200, Ralf Wildenhues wrote: > [ Alexander, the patch to work around shell bugs on your platform breaks > on other ones. As the failure on yours are "more" harmless, I'd like to > revert them. See the thread on the libtool mailing list. ] > > * Nicolas Joly wrote on Thu, May 19, 2005 at 12:39:43AM CEST: > > On Wed, May 18, 2005 at 11:09:21PM +0200, Ralf Wildenhues wrote: > > > * Nicolas Joly wrote on Wed, May 18, 2005 at 05:03:05PM CEST: > > > > > > > > I can't even compile libtool 1.5.18 on my Tru64 unix V5.1B > > > > workstation: > > > *snip* > > > > /bin/ksh ./libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I. > > > > -I. -g -c -o ltdl.lo ltdl.c > > > > libtool: compile: libobj name `ltdl.lo' may not contain shell special > > > > characters. > > > > *** Exit 1 > > > > > > That'll teach me to ever do fatal errors based on shell correctness > > > assumptions again. :( > > OK to apply this patch to branch-2-0 and HEAD, and then backport to > branch-1-5? Sorry for the delay. 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. The first failure seems to be related to missing `print' command in default `/bin/sh': [EMAIL PROTECTED] [~]> /bin/sh $ print -r '\t' print: not found [EMAIL PROTECTED] [~]> BIN_SH=xpg4 /bin/sh $ print -r '\t' \t [EMAIL PROTECTED] [~]> /bin/ksh $ print -r '\t' \t gmake[3]: Entering directory `/home/njoly/temp/libtool-2.1a/libltdl' source='loaders/preopen.c' object='libltdl_la-preopen.lo' libtool=yes \ DEPDIR=.deps depmode=tru64 /bin/sh ../config/depcomp \ /bin/sh ../libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H="" -DLTDL -I. -I. -I.. -DLTDLOPEN=libltdl -I. -I. -I./libltdl -g -c -o libltdl_la-preopen.lo `test -f 'loaders/preopen.c' || echo './'`loaders/preopen.c ../libtool: print: not found ../libtool: print: not found ../libtool: : Permission denied ../libtool: print: not found sh: /: cannot execute gmake[3]: *** [libltdl_la-preopen.lo] Error 1 -- Nicolas Joly Biological Software and Databanks. Institut Pasteur, Paris.
