On 9 September 2010 15:33, kcrisman <kcris...@gmail.com> wrote:
>> > > William said here
>>
>> > >http://groups.google.com/group/sage-devel/browse_thread/thread/1b6235...
>>
>> > > "Probably the only platforms that get g95 are older OS X."
>>
>> > It seems like PowerPC gets it.
>>
>> Well, I run MacOSX 10.5 on my PPC (G4), and I have gfortran.
> Can you give me a command to check this on my own (G4, but running
> 10.4) machine? As noted above, I can't get the command which should
> work to work. local/bin/which_fortran is one of those Perl scripts
> looking for G95, by the way.
>
>> I would propose dropping support for g95...
> If it doesn't break 10.4 support, I would agree.
I think its appropiate if I split my question into two.
1) Can we remove code just in *ATLAS* that checks to see if a previous
installation of ATLAS was built with g95 or not?
2) Can we remove all code in the whole of Sage that worries about g95.
Let's consider both cases - first ATLAS, then the more general one.
1) ATLAS
Given we do not install ATLAS on OS X at all, we can discount issues
related to OS X.
The *only* justification I can see for keeping the code below in ATLAS
is that someone could have a very old Linux system with a
pre-installed version of ATLAS that has a shared library built with
g95. If they then try to build Sage with gfortran on that very old
system, it could break.
The code below, which is in the ATLAS package *may* detect that and
exit with an error message. I say *may* since the shared library that
is tested (ibf77blas.so) is not reliably built on Linux.
This code generates a harmless error on Solaris, as there is no
"readelf" command. But it does not cause any problems. It's just a bit
annoying to have code generating error messages, when IMHO the problem
this attempts to solve is not worth worrying about in 2010.
##########################################################
##########################################################
s_gfortran = os.popen2('readelf -s '
+ATLAS_LIB+'/lib/libf77blas.so | grep gfortran')[1].read()
s_g95 = os.popen2('readelf -s ' + ATLAS_LIB +
'/lib/libf77blas.so | grep g95')[1].read()
if s_gfortran !='' and not fortran.startswith('gfortran'):
print "Symbols in lib77blas indicate it was build with
gfortran \n"
print "However SAGE is using a different fortran compiler \n"
print "If you wish to use this blas library, make sure
SAGE_FORTRAN points \n"
print "to a fortran compiler compatible with this library. \n"
sys.exit(2)
if s_g95 !='' and not fortran.startswith('g95'):
print "Symbols in lib77blas indicate it was build with g95 \n"
print "However SAGE is using a different fortran compiler \n"
print "If you wish to use this blas library, make sure
SAGE_FORTRAN points \n"
print "to a fortran compiler compatible with this library. \n"
sys.exit(2)
##########################################################
##########################################################
2) The next question is whether we should remove *all* code in Sage
that make a distinction between g95 and gfortran. I propose that Sage
still allows one to specify a Fortran compiler with SAGE_FORTRAN, but
if that's not set, it just uses gfortran and does not consider g95.
Note, Sage used to ship with g95 binaries, but they have since been removed. See
http://trac.sagemath.org/sage_trac/ticket/7485
So Sage is definitely moving away from g95.
I'm *NOT* proposing we stop someone building Sage with g95 if they
really want to. Let them try, and set
$ export SAGE_FORTRAN=/path/to/g95
in much the same was I would do on Solaris with
$ export SAGE_FORTRAN=/opt/sunstudio12.1/bin/f95
(note f95, not g95)
I just think we should remove the odd code (much of it rather ugly,
often written in perl), which makes a distinction between gfortran and
g95.
Dave
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
