-
-
Notifications
You must be signed in to change notification settings - Fork 491
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
build/pkgs/gfortran/spkg-configure.m4 works incorrectly if CC and CXX are already there #26715
Comments
This comment has been minimized.
This comment has been minimized.
comment:2
It appears that all what's needed is --- a/build/pkgs/gfortran/spkg-configure.m4
+++ b/build/pkgs/gfortran/spkg-configure.m4
@@ -14,7 +14,6 @@ SAGE_SPKG_CONFIGURE([gfortran], [
# compiler.
if test -z "$FC"; then
sage_spkg_install_gfortran=yes
- SAGE_MUST_INSTALL_GCC([a Fortran compiler is missing])
fi
# see http://www.gnu.org/software/hello/manual/autoconf/Fortran-Compiler.html with this change, and no gfortran in Could someone with access to OSX please try this? (Don't forget to run ./bootstrap before |
comment:3
This is all a bit tricky. What control logic is there when you don't have gfortran (so that the above check will say |
comment:4
Replying to @kiwifb:
There is |
comment:5
Replying to @dimpase:
It doesn't but the the section of code you point too in the diff can only be reached if The only real issue to be careful here is that the gcc bit needs to be run before the gfortran bit. If we go by lexical order everything is fine in this particular case. But that may be something to remember if there is ever another package with an "optional split" or a where checking a dependency first is important. |
comment:6
It seems to be the case for "package Bar provides functionality Foo" kind of stuff that one can dive in :-P Should this Sage component be called YAPS (Yet Another Packaging System)? And by virtue of name it must be implemented in yaml... |
comment:7
Amusing. But more seriously your diff certainly point to an issue that needs to be fixed and is logically what we are after. However the line probably should be replaced with a notice. It was probably the intent in the first place. When do you intend to submit a branch for review? |
comment:9
Replying to @kiwifb:
I think having some kind of notice was the intent, though written exactly as I did was probably a mistake on my part. Looking at the diff from #24919, this is the original code I removed from -# Check that the Fortran compiler accepts free-format source code
-# (as opposed to the older fixed-format style from Fortran 77).
-# This helps verify the compiler works too, so if some idiot
-# sets FC to /usr/bin/ls, we will at least know it's
-# not a working Fortran compiler.
-AC_LANG(Fortran)
-if test -z "$FC"; then
- need_to_install_gfortran=yes
-else and this is the equivalent code that was moved to + # Check that the Fortran compiler accepts free-format source code (as
+ # opposed to the older fixed-format style from Fortran 77).
+ # This helps verify the compiler works too, so if some idiot sets FC to
+ # /usr/bin/ls, we will at least know it's not a working Fortran
+ # compiler.
+ if test -z "$FC"; then
+ sage_spkg_install_gfortran=yes
+ SAGE_MUST_INSTALL_GCC([a Fortran compiler is missing])
+ fi The use of the As Dima suggested it can just be removed and/or replaced with an |
comment:10
Actually, I think there needs to be a bit more logic restructuring too. That |
comment:11
I'd say we're wedded to gfortran too much. As far as I know, flang is in a good state, and a good candidate to replace gfortran (well, yes, it's not that fast yet, but, OK...). This ticket would be a good occasion to fix this, and check for presence of a meaningful Fortran compiler, not specifically gfortran. |
comment:12
This really isn't specifically about gfortran. It is, in fact, just checking that a fortran compiler exists, and if not is installing gfortran. Let's not overcomplicate things here: We've identified a simple fix. I'll attach a patch if no one else does. |
comment:13
Replying to @embray:
Please do. |
comment:14
Replying to @dimpase:
If flang is pretty good, then can you open another ticket to add it as an optional package? It would be nice to have a quicker way to build Sage on OS X for users who don't want to install their own gfortran. |
comment:15
flang does not run on OSX yet. It does run on Linux and FreeBSD, though. |
comment:16
But building |
comment:17
imho Sage should not be in business of building compilers. |
Branch: u/fbissey/fortran |
Commit: |
Author: François Bissey |
comment:18
OK does this branch satisfy everyone. New commits:
|
Branch pushed to git repo; I updated commit sha1. New commits:
|
comment:20
Stuff is broken, trying to figure out why. New commits:
|
comment:21
OK that was weird. After running It seems like that macro doesn't really like to live in a conditional. In fact it looks like it goes next to AC_PROG_FC all by itself. AC_PROG_FC (and also CC and CXX) is currently called in I also learned a few things about |
comment:22
I also did some testing with
This is also nicely triggered if there is no |
comment:24
I left the issue of multiple calls to |
comment:25
For the record I just built and successfully doctested sage with this ticket and the PGI fortran compiler. A couple of issues with doing that though. More about it in the morning before I move to Intel compilers. |
comment:26
Builds for me on OS X Mojave with my gfortran compiler temporarily removed. The Sage |
comment:27
The |
Reviewer: Erik Bray |
comment:28
Replying to @jhpalmieri:
That's because this involves compiling most, if not all, of gcc and only installing the gfortran bits. |
comment:29
Replying to @embray:
I understand that, I just wish we could build a fortran compiler more quickly. (That's why I install |
comment:30
Totally happy if someone wants to look into that. Too bad flang is (according to François) still difficult to install on macOS, which would defeat some of the purpose :( |
comment:31
Replying to @embray:
It's a pain on all OS full stop. I think you have to have a private patched build of llvm, you cannot reuse clang bits if you have them. I won't recommend PGI fortran (needs hand holding) but ifc may be fine, I can try other suggestions if I have access to them. |
comment:32
OK wrap up for people interested in using something like pgfortran, you can get it from https://www.pgroup.com/ . Set your environment
and once done resume the build normally. Don't define |
patch to compile openblas properly with pgfortran |
comment:33
Attachment: pgfortran.patch.gz Does non-Apple clang pretend to be GCC? How? Just wondering. |
comment:34
Replying to @dimpase:
It does. Compiler identification is by pragma, and clang on OS X or otherwise has the pragmas saying it is gcc-4.2.1. The intel compiler is a bit different, at installation time it will look at your default gcc install and mimic all the needed pragmas to fake it. Both compiler still have their own vendor pragmas. But by default |
Changed branch from u/fbissey/fortran to |
comment:36
And at last for those still interested I did a build with gcc+ifort (intel fortran compiler). Same kind of set up as for PGI. I had to also provide openblas need the upgrade to 0.3.3 because of this OpenMathLib/OpenBLAS#1548 R is still fiddly and you still need to define Anyway everything was sorted and built properly sage works and pass its doctests with flying colours on linux. Adding intel for C/C++ requires adjustment in pari and possibly sqlite from what I remember. But this is an alternative that could really be made to work. |
Changed commit from |
As a result of refactoring configure.ac in #24919,
absence of (g)fortran now forces installation of full gcc, instead of just gfortran part of it.
This is particularly crucial on OSX, where we don't normally build full gcc any more, but only build gfortran.
To reproduce, move gfortran out of your PATH, and re-run ./configure. You'll see that now
gcc
andgfortran
are scheduled for installation...CC: @embray @jhpalmieri @vbraun @kiwifb
Component: build: configure
Author: François Bissey
Branch:
3185e91
Reviewer: Erik Bray
Issue created by migration from https://trac.sagemath.org/ticket/26715
The text was updated successfully, but these errors were encountered: