Re: Tru64 Fortran compiler support (was: FYI: ksh bug on Tru64 UNIX causes current libtool failure)

2005-10-07 Thread Nicolas Joly 
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

2005-10-06 Thread Ralf Wildenhues 
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

2005-10-06 Thread Nicolas Joly 
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

2005-10-05 Thread Ralf Wildenhues 
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

2005-10-04 Thread 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?

[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

FYI: ksh bug on Tru64 UNIX causes current libtool failure

2005-08-28 Thread Ralf Wildenhues 
This is the ancient bug report about the Tru64 shell.

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

 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

The Tru64 shell does not like us to close stdin.  It will corrupt its
memory which will become apparent when FD operations are done the next
time.

I've applied the patch below to HEAD to finally fix this issue.
Gary helped me analyze it -- many thanks to everyone that provided
input to this!

Cheers,
Ralf

2005-08-28  Ralf Wildenhues  [EMAIL PROTECTED],
Gary V. Vaughan  [EMAIL PROTECTED]

* libltdl/config/ltmain.m4sh (func_lalib_unsafe_p) [osf]:
Save file descriptor to original STDIN, and restore after
redirection.  Fixes memory corruption with Tru64 and OSF sh.
Reported by Nicolas Joly [EMAIL PROTECTED].

Index: libltdl/config/ltmain.m4sh
===
RCS file: /cvsroot/libtool/libtool/libltdl/config/ltmain.m4sh,v
retrieving revision 1.4
diff -u -r1.4 ltmain.m4sh
--- libltdl/config/ltmain.m4sh  24 Aug 2005 15:57:32 -  1.4
+++ libltdl/config/ltmain.m4sh  28 Aug 2005 15:28:37 -
@@ -603,7 +603,7 @@
 func_lalib_unsafe_p ()
 {
 lalib_p=no
-if test -r $1  exec $1; then
+if test -r $1  exec 51 $1; then
for lalib_p_l in 1 2 3 4
do
read lalib_p_line
@@ -611,7 +611,7 @@
\#\ Generated\ by\ *$PACKAGE* ) lalib_p=yes; break;;
esac
done
-   exec -
+   exec 15 5-
 fi
 test $lalib_p = yes
 }

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

2005-07-06 Thread Ralf Wildenhues 
* 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