SAGE_FORTRNA on OS X.
Dr. David Kirkby
someone sets SAGE_FORTRAN on OS X? Should Sage use that compiler, or just ignore
it and use its own?
I'm currently updating prereq. I believe I have all the code in place to check
for the presence of the C/C++ and Fortran compilers, check they are all the same
version if GNU ones, and check there is not a mix of GNU and non-GNU compilers.
There seems to be 3 possibilities with OS X, and I'm not sure of the intended
behaviour.
1) Use the binary included in Sage at all times.
2) Try to find a binary of gfortran, but if not found, then use the one built in.
3) Always use one is specified by SAGE_FORTRAN.
Let me know how to handle the OS X case, and I'll complete an update to sage-env.
I finally found a way of confirming the version of the fortran compiler is the
same as gcc and gcc+. The behaviour of the fortran compiler is different here.
drkirkby@hawk:~$ gcc -dumpversion
4.3.4
drkirkby@hawk:~$ g++ -dumpversion
4.3.4
provide an easy way of getting the version number. gfortran is less helpful.
drkirkby@hawk:~$ gfortran -dumpversion
GNU Fortran (GCC) 4.3.4
Copyright (C) 2008 Free Software Foundation, Inc.
GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of GNU Fortran
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING
But I think a 'gfortran -dumpversion | grep 4.3.4' should show some output if
gfortran is version 4.3.4, and not otherwise.
In GCC 4.5, the odd behaviour of fgortran is fixed, but that does not help us
now, and will not for many years, until such time as the gcc 4.4.x series are
too old to build Sage, which hopefully wont be in the short time.
Dave
William Stein
<david....@onetel.net> wrote:
> I know OS X comes with its own binary fortran compiler. But what happens if
> someone sets SAGE_FORTRAN on OS X? Should Sage use that compiler, or just
> ignore it and use its own?
Sage should use it.
> I'm currently updating prereq. I believe I have all the code in place to
> check for the presence of the C/C++ and Fortran compilers, check they are
> all the same version if GNU ones, and check there is not a mix of GNU and
> non-GNU compilers.
>
> There seems to be 3 possibilities with OS X, and I'm not sure of the
> intended behaviour.
>
> 1) Use the binary included in Sage at all times.
> 2) Try to find a binary of gfortran, but if not found, then use the one
> built in.
> 3) Always use one is specified by SAGE_FORTRAN.
NONE of the above.
4) Use the binary included in Sage if SAGE_FORTRAN is not specified.
Otherwise, use the one pointed to by the that environment variable.
>
> Let me know how to handle the OS X case, and I'll complete an update to
> sage-env.
>
> I finally found a way of confirming the version of the fortran compiler is
> the same as gcc and gcc+. The behaviour of the fortran compiler is different
> here.
>
> drkirkby@hawk:~$ gcc -dumpversion
> 4.3.4
> drkirkby@hawk:~$ g++ -dumpversion
> 4.3.4
>
> provide an easy way of getting the version number. gfortran is less helpful.
>
>
> drkirkby@hawk:~$ gfortran -dumpversion
> GNU Fortran (GCC) 4.3.4
> Copyright (C) 2008 Free Software Foundation, Inc.
>
> GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
> You may redistribute copies of GNU Fortran
> under the terms of the GNU General Public License.
> For more information about these matters, see the file named COPYING
>
> But I think a 'gfortran -dumpversion | grep 4.3.4' should show some output
> if gfortran is version 4.3.4, and not otherwise.
>
> In GCC 4.5, the odd behaviour of fgortran is fixed, but that does not help
> us now, and will not for many years, until such time as the gcc 4.4.x series
> are too old to build Sage, which hopefully wont be in the short time.
>
> Dave
>
>
>
>
> --
> To post to this group, send an email to sage-...@googlegroups.com
> To unsubscribe from this group, send an email to
> sage-devel+...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org
>
--
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org
Jaap Spies
> On Sat, Jan 23, 2010 at 1:33 PM, Dr. David Kirkby
> <david....@onetel.net> wrote:
>> I know OS X comes with its own binary fortran compiler. But what happens if
>> someone sets SAGE_FORTRAN on OS X? Should Sage use that compiler, or just
>> ignore it and use its own?
>
> Sage should use it.
>
>> I'm currently updating prereq. I believe I have all the code in place to
>> check for the presence of the C/C++ and Fortran compilers, check they are
>> all the same version if GNU ones, and check there is not a mix of GNU and
>> non-GNU compilers.
>>
>> There seems to be 3 possibilities with OS X, and I'm not sure of the
>> intended behaviour.
>>
>> 1) Use the binary included in Sage at all times.
>> 2) Try to find a binary of gfortran, but if not found, then use the one
>> built in.
>> 3) Always use one is specified by SAGE_FORTRAN.
>
> NONE of the above.
>
> 4) Use the binary included in Sage if SAGE_FORTRAN is not specified.
> Otherwise, use the one pointed to by the that environment variable.
>
There is a hiatus in the spkg-install. If you only export SAGE_FORTRAN
on Open Solaris with SAGE64="yes" the script picks up the wrong lib.
../lib/amd64/libgfortran is needed.
Jaap
Dr. David Kirkby
> There is a hiatus in the spkg-install. If you only export SAGE_FORTRAN
> on Open Solaris with SAGE64="yes" the script picks up the wrong lib.
>
> ../lib/amd64/libgfortran is needed.
That is not going to work on SPARC though. Instead, use:
../lib/`isainfo -n`/libgfortran.so
as that will substitute the correct library on either Solaris platform. (It's
not portable across other platforms though - AIX, HP-UX etc)
SAGE_FORTRAN and SAGE_FORTRAN_LIB are quite separate things.
SAGE_FORTRAN has nothing to do with the library.
In fact, with the Sun compilers, there is no need to set SAGE_FORTRAN_LIB.
With the GNU compilers, you can usually ignore it if you install in /usr/local,
but the problem with that is /usr/local can become a mess, and it makes it
impractical to have multiple versions of a compiler.
Of course, a lot of people add /usr/local/lib to the default path searched by
the linker.
An ideal solution would be for it to be possible to hard-code the location of
the libraries. I have contemplated used 'sed' on the GCC tar file and
substituting /usr/local for wherever I want to install the files and libraries.
Then it should find the right library, and no other.
Dave
Jaap Spies
> Jaap Spies wrote:
>
>> There is a hiatus in the spkg-install. If you only export SAGE_FORTRAN
>> on Open Solaris with SAGE64="yes" the script picks up the wrong lib.
>>
>> ../lib/amd64/libgfortran is needed.
>
> That is not going to work on SPARC though. Instead, use:
>
> ../lib/`isainfo -n`/libgfortran.so
>
> as that will substitute the correct library on either Solaris platform.
> (It's not portable across other platforms though - AIX, HP-UX etc)
>
> SAGE_FORTRAN and SAGE_FORTRAN_LIB are quite separate things.
>
> SAGE_FORTRAN has nothing to do with the library.
>
The only point I would like to make is that the script as is picks up
the wrong lib if SAGE_FORTRAN_LIB is not set to the right libgfortran.so
Jaap
Dr. David Kirkby
It would be good if there was a check that SAGE_FORTRAN_LIB was pointing at a
64-bit library, if the build is 64-bit. I know that was one of the mistakes I made.
There's some discussion of this at
http://trac.sagemath.org/sage_trac/ticket/7484
I could add such a check in 'prereq' to make sure that SAGE_FORTRAN_LIB was a
64-bit library if SAGE64 was exported to yes. (I could work out how to do that
on Solaris and HP-UX, but I'm not sure how to handle it on OS X).
The problem with 'prereq' is that it is only run at the start of the build, and
not again if the build fails, and someone restarts it. But doing a test there,
is better than doing no tests at all.
Dave
Jaap Spies
OS X is a case on its own. Forced to use the included binary, as far as I
understand things.
On Open Solaris things went wrong with the spkg-install python scrypt
assuming the libgfortran.so is ../../lib/libgfortran.so in stead of
(you and I know) ../../lib/amd64/libgfortran.so :(
Jaap
Dr. David Kirkby
Sort of, but if you note what William said above, it is possible to use another
compiler on OS X, and it should be used in preference to the included one if
SAGE_FORTRAN is set.
> On Open Solaris things went wrong with the spkg-install python scrypt
> assuming the libgfortran.so is ../../lib/libgfortran.so in stead of
> (you and I know) ../../lib/amd64/libgfortran.so :(
>
> Jaap
Yes it will. But also bear in mind it will go wrong if you use 'amd64' on SPARC.
Actually, the best way, is probably to use '64' rather than 'amd64' or
'sparcv9', as on both systems, 64 is a symbolic link. On Solaris x86:
drkirkby@hawk:~$ ls -ld /usr/lib/64
lrwxrwxrwx 1 root root 5 Oct 26 17:17 /usr/lib/64 -> amd64
drkirkby@hawk:~$
On Solaris SPARC
drkirkby@swan:[~/sage-4.3.1/spkg/base/prereq-0.7] $ ls -ld /usr/lib/64
lrwxrwxrwx 1 root root 7 Jul 11 2009 /usr/lib/64 -> sparcv9
drkirkby@swan:[~/sage-4.3.1/spkg/base/prereq-0.7] $
The same is true in /usr/local.