[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: FYI: ksh bug on Tru64 UNIX causes current libtool failure
From: |
Ralf Wildenhues |
Subject: |
Re: FYI: ksh bug on Tru64 UNIX causes current libtool failure |
Date: |
Thu, 6 Oct 2005 14:27:26 +0200 |
User-agent: |
Mutt/1.5.11 |
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 2>&1
> libtool: compile: f95 -c -g b.f -o .libs/b.o
> libtool: compile: f95 -c -g b.f -o b.o >/dev/null 2>&1
> libtool: compile: f95 -c -g c.f -o .libs/c.o
> libtool: compile: f95 -c -g c.f -o c.o >/dev/null 2>&1
> libtool: compile: f95 -c -g main.f -o .libs/main.o
> libtool: compile: f95 -c -g main.f -o main.o >/dev/null 2>&1
> 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 code was 1, expected 0
> 10. convenience.at:116: 10. FC convenience archives (convenience.at:116):
> FAILED (convenience.at:150)
>
>
> ## ------------- ##
> ## ../config.log ##
> ## ------------- ##
> | configure:16498: checking if libtool supports shared libraries
> | configure:16500: result: yes
> | configure:16503: checking whether to build shared libraries
> | configure:16523: result: yes
> | configure:16526: checking whether to build static libraries
> | configure:16530: result: yes
> | configure:16546: checking for f77 option to produce PIC
> | configure:16773: result:
> | configure:16837: checking if f77 static flag -non_shared works
> | configure:16865: result: yes
> | configure:16877: checking if f77 supports -c -o file.o
> | configure:16898: f77 -c -g -o out/conftest2.o conftest.f >&5
> | configure:16902: $? = 0
> | configure:16924: result: yes
> | configure:16929: checking if f77 supports -c -o file.o
> | configure:16976: result: yes
> | configure:17006: checking whether the f77 linker (/usr/bin/ld) supports
> shared libraries
> | configure:17971: result: yes
> | configure:18110: checking dynamic linker characteristics
> | configure:18684: result: osf5.1b ld.so
> | configure:18720: checking how to hardcode library paths into programs
> | configure:18745: result: immediate
> | configure:18763: checking whether stripping libraries is possible
> | configure:18785: result: no
> | configure:19037: result: yes
> | configure:19159: checking if libtool supports shared libraries
> | configure:19161: result: yes
> | configure:19164: checking whether to build shared libraries
> | configure:19184: result: yes
> | configure:19187: checking whether to build static libraries
> | configure:19191: result: yes
> | configure:19219: f95 -c -g conftest.f >&5
> | configure:19222: $? = 0
> | configure:19331: checking for f95 option to produce PIC
> | configure:19558: result:
> | configure:19622: checking if f95 static flag -non_shared works
> | configure:19650: result: yes
> | configure:19662: checking if f95 supports -c -o file.o
> | configure:19683: f95 -c -g -o out/conftest2.o conftest.f >&5
> | configure:19687: $? = 0
> | configure:19709: result: yes
> | configure:19714: checking if f95 supports -c -o file.o
> | configure:19761: result: yes
> | configure:19791: checking whether the f95 linker (/usr/bin/ld) supports
> shared libraries
> | configure:20756: result: yes
> | configure:20895: checking dynamic linker characteristics
> | configure:21469: result: osf5.1b ld.so
> | configure:21505: checking how to hardcode library paths into programs
> | configure:21530: result: immediate
> | configure:21548: checking whether stripping libraries is possible
> | configure:21570: result: no
- Re: FYI: ksh bug on Tru64 UNIX causes current libtool failure, Nicolas Joly, 2005/10/03
- Re: FYI: ksh bug on Tru64 UNIX causes current libtool failure, Ralf Wildenhues, 2005/10/04
- Re: FYI: ksh bug on Tru64 UNIX causes current libtool failure, Nicolas Joly, 2005/10/04
- Re: FYI: ksh bug on Tru64 UNIX causes current libtool failure, Ralf Wildenhues, 2005/10/05
- Re: FYI: ksh bug on Tru64 UNIX causes current libtool failure, Nicolas Joly, 2005/10/05
- FYI: fix simple C++ link code m4 quoting (was: FYI: ksh bug on Tru64 UNIX causes current libtool failure), Ralf Wildenhues, 2005/10/05
- Re: FYI: ksh bug on Tru64 UNIX causes current libtool failure,
Ralf Wildenhues <=
- Re: FYI: ksh bug on Tru64 UNIX causes current libtool failure, Nicolas Joly, 2005/10/06
- Tru64 Fortran compiler support (was: FYI: ksh bug on Tru64 UNIX causes current libtool failure), Ralf Wildenhues, 2005/10/06
- Re: Tru64 Fortran compiler support (was: FYI: ksh bug on Tru64 UNIX causes current libtool failure), Nicolas Joly, 2005/10/07
- Re: FYI: ksh bug on Tru64 UNIX causes current libtool failure, Nicolas Joly, 2005/10/07