Fedora 42 too new?

[Nils Bruin]

I'm getting this error from configure for sage:

real_configure: Installing GCC because g++ -std=gnu++11 is g++ version 15, which is too recent for this version of Sage

no building sage on Fedora 42 yet?

[Dima Pasechnik]

we're getting there, see 

https://github.com/sagemath/sage/pull/39977 (needs review)

https://github.com/sagemath/sage/pull/39985

https://github.com/sagemath/sage/pull/40033

--
You received this message because you are subscribed to the Google Groups "sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/sage-devel/a987dba2-7285-49bf-9a2b-00473844f27dn%40googlegroups.com.

[Vincent Macri]

As a workaround until GCC 15 is supported, this worked for me:

export CC=$(which gcc-14)
export CPP=$(which cpp-14)
export CXX=$(which g++-14)
export FC=$(which gfortran-14)

these can be installed via the Fedora packages gcc14, gcc14-c++, and
gcc14-gfortran.

Vincent Macri (He/Him)

[Nils Bruin]

Thanks! that's a useful tip. When do you need repeat this? For any make? just configure? just bootstrap?

[Vincent Macri]

I think just before configure, but I didn't do any testing to verify
that's the only place you need it. I just ran it once then did all the
steps to build from source without closing the terminal.

[Dima Pasechnik]

By right, once  ./configure is  run,  it all good, the compilers are set.

Note that updates to Sage often trigger a ./configure, or even a ./bootstrap, run, so you need to be prepared for this.

Dima

  

--
You received this message because you are subscribed to the Google Groups "sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/sage-devel/3d474d71-81ec-4007-abfb-4f6cdb45b6e4%40ucalgary.ca.

[Nils Bruin]

This ended up not quite working for me anymore. The "build" didn't produce an error, but sage crashes upon startup because:

...

  File "sage/algebras/quatalg/quaternion_algebra_cython.pyx", line 1, in init sage.algebras.quatalg.quaternion_algebra_cython
    # distutils: language = c++
ImportError: libflint.so.19: cannot open shared object file: No such file or directory

I think something might have gone wrong in the configuration:

$ sage --python
Python 3.13.5 (main, Jun 12 2025, 00:00:00) [GCC 15.1.1 20250521 (Red Hat 15.1.1-2)] on linux

Would that be a source of trouble?

This file /usr/lib64/libflint.so.19 does exist. On the other hand:

$ ldd quaternion_algebra_cython.cpython-313-x86_64-linux-gnu.so
linux-vdso.so.1 (0x00007f61ea097000)
libgmp.so.10 => /lib64/libgmp.so.10 (0x00007f61e9fb2000)
libntl.so.44 => /lib64/libntl.so.44 (0x00007f61e9c00000)
libflint.so.20 => /lib64/libflint.so.20 (0x00007f61e9000000)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f61e8c00000)
libm.so.6 => /lib64/libm.so.6 (0x00007f61e9ec4000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f61e9bd4000)
libc.so.6 => /lib64/libc.so.6 (0x00007f61e8a0e000)
libgf2x.so.3 => /lib64/libgf2x.so.3 (0x00007f61e9eb1000)
libflexiblas.so.3 => /lib64/libflexiblas.so.3 (0x00007f61e8600000)
libmpfr.so.6 => /lib64/libmpfr.so.6 (0x00007f61e8f44000)
/lib64/ld-linux-x86-64.so.2 (0x00007f61ea099000)
libgfortran.so.5 => /lib64/libgfortran.so.5 (0x00007f61e8200000)
libquadmath.so.0 => /lib64/libquadmath.so.0 (0x00007f61e9b8d000)

so it seems that while compiling, another libflint was picked up. That one indeed exists as well.

I did bootstrap and configure. Should I "make distclean" as well?

[Nils Bruin]

On Thursday, 3 July 2025 at 17:25:48 UTC-7 Nils Bruin wrote:

This file /usr/lib64/libflint.so.19 does exist.

 Apologies. Does NOT exist.

[Michael Orlitzky]

On 2025-07-03 17:25:48, Nils Bruin wrote:
> # distutils: language = c++
> ImportError: libflint.so.19: cannot open shared object file: No such file
> or directory
>

> ...

>
> I did bootstrap and configure. Should I "make distclean" as well?

Yes, whenever you upgrade one of sage's dependencies in a way that
changes its ABI (i.e. changes the library file name), many different
parts of sage need to be rebuilt. We don't really keep track of which
parts, so the only thing that works reliably is to nuke the existing
sage installation and start over.

[Dima Pasechnik]

Hi Nils,

with two dylibs like this, you are basically at the mercy of the linker.

E.g. OS updates often lead to this sort of thing, and indeed you might want to clean and rebuild all the consumers of libflint.so,
which you can see by

git grep flint build/pkgs/*/dep*

(some of these you might not have installed and some might come from OS, so these should be fine)

Dima

[Dima Pasechnik]

OK, then it's just a straightforward rebuild

[Nils Bruin]

Thanks! This worked for me once I told sage to NOT use the system ecl: it is configured to use GCC15 (and I don't see how to change that), which then leads to problems with building maxima. Building your own ecl does lead to an ecl that uses gcc-14, which then builds maxima without problems.

On Sunday, 4 May 2025 at 10:35:06 UTC-7 Vincent Macri wrote: