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. 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. - 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.
