[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Tru64 Fortran compiler support (was: FYI: ksh bug on Tru64 UNIX causes c
From: |
Ralf Wildenhues |
Subject: |
Tru64 Fortran compiler support (was: FYI: ksh bug on Tru64 UNIX causes current libtool failure) |
Date: |
Thu, 6 Oct 2005 18:27:32 +0200 |
User-agent: |
Mutt/1.5.11 |
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.
> >
> > 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.
Cool!
> > 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.
Good.
> Tru64 fortran compilers do not support `-expect_unresolved \*' option
> directly. Passing it prefixed with `-Wl,' solves the problem.
>
> All others seems to work directly :
*snip*
Very nice, thanks for testing!
> > 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..
> > 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
Cheers,
Ralf
Index: libltdl/m4/libtool.m4
===================================================================
RCS file: /cvsroot/libtool/libtool/libltdl/m4/libtool.m4,v
retrieving revision 1.25
diff -u -r1.25 libtool.m4
--- libltdl/m4/libtool.m4 5 Oct 2005 15:57:05 -0000 1.25
+++ libltdl/m4/libtool.m4 6 Oct 2005 16:25:31 -0000
@@ -4472,7 +4472,12 @@
_LT_TAGVAR(archive_cmds, $1)='$CC -shared${allow_undefined_flag}
$libobjs $deplibs $compiler_flags ${wl}-msym ${wl}-soname ${wl}$soname `test -n
"$verstring" && $ECHO "X${wl}-set_version ${wl}$verstring" | $Xsed`
${wl}-update_registry ${wl}${output_objdir}/so_locations -o $lib'
_LT_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-rpath ${wl}$libdir'
else
- _LT_TAGVAR(allow_undefined_flag, $1)=' -expect_unresolved \*'
+ case $cc_basename in
+ f77* | f90* | f95*)
+ _LT_TAGVAR(allow_undefined_flag, $1)=' ${wl}-expect_unresolved
${wl}\*' ;;
+ *)
+ _LT_TAGVAR(allow_undefined_flag, $1)=' -expect_unresolved \*' ;;
+ esac
_LT_TAGVAR(archive_cmds, $1)='$CC -shared${allow_undefined_flag}
$libobjs $deplibs $compiler_flags -msym -soname $soname `test -n "$verstring"
&& $ECHO "X-set_version $verstring" | $Xsed` -update_registry
${output_objdir}/so_locations -o $lib'
_LT_TAGVAR(archive_expsym_cmds, $1)='for i in `cat $export_symbols`; do
printf "%s %s\\n" -exported_symbol "\$i" >> $lib.exp; done; printf "%s\\n"
"-hidden">> $lib.exp~
$CC -shared${allow_undefined_flag} -input $lib.exp $compiler_flags
$libobjs $deplibs -soname $soname `test -n "$verstring" && $ECHO "X-set_version
$verstring" | $Xsed` -update_registry ${output_objdir}/so_locations -o $lib~$RM
$lib.exp'
- 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, 2005/10/06
- 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 <=
- 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