On Tue, Nov 26, 2024 at 10:58 AM Marc Culler <[email protected]> wrote: > > You cannot just "get rid of the gcc package". It is not that simple. > > Getting rid of the gcc package means that you also get rid of the gfortran > package. The way that Sage builds gfortran is that it builds part of gcc > (the gnu compiler collection). That part has to include gfortran, of course, > but it also has to include the gcc C compiler, since the way that gcc builds > gfortran is that it first builds a C compiler and then uses that to build > gfortran.
Let's concentrate on "gcc package" as the ability of Sage to build and use its own gcc and g++ compilers. Removing this ability does not remove the ability to build gfortran (even if it involves building an internal copy of a C compiler). What's important is that this internal copy of the C compiler is in no way used for anything except building gfortran. (the C compiler not even installed anywhere) Do you have any objections to removing gcc package in this sense? If not, we can proceed with this at least, and proceed to discussing Fortran. Yes, you are right that we certainly will want to remove the ability to build gfortran, as well, as gfortran is also available on all the supported platforms. And this is now a macOS-only issue. > > To build a C compiler one first uses a pre-existing C compiler, clang in the > case of macOS, to build version 1 of the new C compiler. Then version 1 is > used to build version 2. Then version 2 is used to build version 3. Then > the executables for version 2 and version 3 are compared. If they are > identical the build is deemed to have succeeded. > > The main reason Sage needs gfortran is because Sage has a numpy spkg, and > numpy needs OpenBLAS. So Sage needs an OpenBlas spkg and that requires a > fortran compiler. If you want to "get rid of gcc" in an intelligent way, the > place to begin would be with numpy. Installing numpy with a binary wheel > from pypi would relieve Sage of the need to build it. OpenBLAS is not > released as a binary package because it attempts to optimize itself for the > specific hardware being used to build it. So it is somewhat tricky to > produce a binary OpenBLAS library which can be expected to work on a wide > range of Intel hardware. Sage attempts to do that, however, as does numpy > for its binary wheels. > > Just making the pronouncement "we should get rid of the gcc package" without > having any discussion of the complicated consequences of attempting to do > that, and without providing any proposal for dealing with those consequences, > is irresponsible in my opinion. And making the predictable next > pronouncement "just use the homebrew gfortran" is also pretty far from > dealing with the consequences, even if it might be part of an eventual > solution. I repeat, from our earlier discussions: Sage is the only open source multiplatform Python project around which tries to carry around an ability to build a Fortran compiler. Projects with much bigger resources (and much bigger user base), with full-time employees, such as numpy/scipy, don't do this. As far as I am concerned, I would be fine with declaring that we don't support building Sage from source on macOS without Homebrew. This would resolve the gfortran issue (subject to the necessary CI, etc, chnages, of course). Another way to have gfortran I am aware of is to use a standalone gfortran macOS package provided by one of maintainers of gfortran in Homebrew. By the way, scipy lately (re)gained the abilty to use Apple's Accelerate library, instead of OpenBlas. This could be something to look into fot Sage, too. Dima > > - Marc > > PS Some detail on the ECM patch. Assembler files can have suffix .s .S or > .sx. The last two imply that the file should be passed through the > preprocessor before being sent to the assembler. The distinction between .s > and .S causes trouble on case-insensitive filesystems. That is the reason > why the .sx extension exists. The ECM build produces .s files which need the > preprocessor because they contain #if and #else. The patch was an attempt > to use .sx for those files instead of .s. Evidently some Apple systems treat > .s as if it were .S and others don't. > > On Tuesday, November 26, 2024 at 7:40:09 AM UTC-6 Kwankyu Lee wrote: >> >> On Tuesday, November 26, 2024 at 8:45:37 PM UTC+9 Dima Pasechnik wrote: >> >> no, I have not yet opened a PR to fix it. >> >> >> The PR should be a blocker. >> >> >> It was added in the PR which upgraded gcc - as it failed to build ecm on a >> macOS system (sic!) >> >> >> On macOS, I think it is the usual scenario that the system gcc(clang) is >> used to build sage. >> >> We should just get rid of the gcc package, it is merely a source of bugs and >> a general development timesink. >> >> >> I am aware that this issue is controversial. But I am no expert in that. >> >> If, on every platform we support, the system gcc is a prerequisite and >> enough to build sage, and to compile cython code in sage sessions, then I >> see no reason for us to carry the gcc package. I wonder what are the main >> arguments against it though. > > -- > You received this message because you are subscribed to the Google Groups > "sage-release" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion visit > https://groups.google.com/d/msgid/sage-release/a20e1e5b-6347-4159-af55-301fd7af5338n%40googlegroups.com. -- You received this message because you are subscribed to the Google Groups "sage-release" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/sage-release/CAAWYfq3CWBzhQPSvg18FRM-YgF2qg3%3DPbQaF0ULPzLELkfX2Ow%40mail.gmail.com.
