Sage 10.7.rc1 released

[Volker Braun]

As always, you can get the latest beta version from the "develop" git branch. Alternatively, the self-contained source tarball is at http://www.sagemath.org/download-latest.html

4a2dac04955 (tag: 10.7.rc1, github/develop) Updated SageMath version to 10.7.rc1
bcdffce78b7 gh-40519: typo + guava
94fe540d332 (tag: 10.7.rc0) Updated SageMath version to 10.7.rc0

[Marc Culler]

I am unable to build gp2c on a manylinux2014 docker image with this release.  There are 3210 errors of the form "multiple definition of X" starting with:

[spkg-install] /opt/rh/devtoolset-10/root/usr/libexec/gcc/x86_64-redhat-linux/10/ld: context.o:(.bss+0x0): multiple definition of `debug_stack'; gp2c.o:(.bss+0x0): first defined here
[spkg-install] /opt/rh/devtoolset-10/root/usr/libexec/gcc/x86_64-redhat-linux/10/ld: context.o:(.bss+0x8): multiple definition of `typemax'; gp2c.o:(.bss+0x8): first defined here

- Marc

[G. M.-S.]

This is on macOS 13.7.7 and macOS 15.6 with Homebrew.

After

./configure --enable-fricas --enable-gap_packages --enable-semigroups --enable-symengine

make succeeds.

And make ptestlong gives 3 permanent failures:

1)

sage -t --long --warn-long 30.0 --random-seed=… src/doc/en/reference/spkg/semigroups.rst
**********************************************************************
File "src/doc/en/reference/spkg/semigroups.rst", line 15, in doc.en.reference.spkg.semigroups
Failed example:
    libgap.LoadPackage("semigroups")       # optional - semigroups
Expected:
    true
Got:
    #I  ReadPackage could not read <digraphs>/gap/doc.g
    <BLANKLINE>
    true
**********************************************************************

already known.

2)

sage -t --long --warn-long 30.0 --random-seed=… src/sage/rings/real_mpfr.pyx
**********************************************************************
File "src/sage/rings/real_mpfr.pyx", line 3331, in sage.rings.real_mpfr.RealNumber._axiom_
Failed example:
    fricas(R(pi))                         # optional - fricas
Expected:
    3.1415926535_8979323846_26433833
Got:
    doctest:warning
[…]

    DeprecationWarning: This process (pid=82208) is multi-threaded, use of forkpty() may lead to deadlocks in the child.
    3.1415926535_8979323846_26433833
**********************************************************************

3)

sage -t --long --warn-long 30.0 --random-seed=132664251215356611384030978294607463879 src/sage/interfaces/fricas.py
**********************************************************************
File "src/sage/interfaces/fricas.py", line 292, in sage.interfaces.fricas.FriCAS.?
Failed example:
    fricas == loads(dumps(fricas))
Exception raised:
    Traceback (most recent call last):
      File "sage/misc/persist.pyx", line 338, in sage.misc.persist.dumps
        ans = type_obj.dumps(obj, compress)
      File "sage/structure/sage_object.pyx", line 508, in sage.structure.sage_object.SageObject.dumps
        return _base_dumps(self, compress=compress)
      File "sage/misc/persist.pyx", line 306, in sage.misc.persist._base_dumps
        gherkin = SagePickler.dumps(obj)
      File "sage/misc/persist.pyx", line 830, in sage.misc.persist.SagePickler.dumps
        pickler.dump(obj)
    TypeError: cannot pickle 'sage.misc.lazy_import.LazyImport' object

    During handling of the above exception, another exception occurred:

    Traceback (most recent call last):
      File "/Users/sagemath/SageMath/Git/sage/src/sage/doctest/forker.py", line 733, in _run
        self.compile_and_execute(example, compiler, test.globs)
        ~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      File "/Users/sagemath/SageMath/Git/sage/src/sage/doctest/forker.py", line 1157, in compile_and_execute
        exec(compiled, globs)
        ~~~~^^^^^^^^^^^^^^^^^
      File "<doctest sage.interfaces.fricas.FriCAS.?[0]>", line 1, in <module>
        fricas == loads(dumps(fricas))
                        ~~~~~^^^^^^^^
      File "sage/misc/persist.pyx", line 340, in sage.misc.persist.dumps
        ans = _base_dumps(obj, compress=compress)
      File "sage/misc/persist.pyx", line 306, in sage.misc.persist._base_dumps
        gherkin = SagePickler.dumps(obj)
      File "sage/misc/persist.pyx", line 830, in sage.misc.persist.SagePickler.dumps
        pickler.dump(obj)
    TypeError: cannot pickle 'sage.misc.lazy_import.LazyImport' object
**********************************************************************

but FriCAS is optional.

Additionally, if TeX is not installed, there is:

4)

sage -t --long --warn-long 30.0 --random-seed=… src/sage/algebras/quantum_groups/quantum_group_gap.py
**********************************************************************
File "src/sage/algebras/quantum_groups/quantum_group_gap.py", line 1583, in sage.algebras.quantum_groups.quantum_group_gap.QuantumGroupModule._latex_
Failed example:
    latex(S)
Expected:
    \begin{tikzpicture}...
    ...
    \end{tikzpicture}
Got:

    <BLANKLINE>
    Warning: `tikz.sty` is not part of this computer's TeX installation.
    This package is required to render graphs in LaTeX.
[…]
**********************************************************************

Guillermo

[G. M.-S.]

This is on Debian 12.

After

./configure --enable-fricas --enable-gap_packages --enable-semigroups --enable-symengine

make succeeds.

And make ptestlong gives 1 permanent failure:

sage -t --long --warn-long 30.0 --random-seed=… src/doc/en/reference/spkg/semigroups.rst

**********************************************************************
File "src/doc/en/reference/spkg/semigroups.rst", line 15, in doc.en.reference.spkg.semigroups
Failed example:
    libgap.LoadPackage("semigroups")       # optional - semigroups
Expected:
    true
Got:
    #I  ReadPackage could not read <digraphs>/gap/doc.g
    <BLANKLINE>
    true
**********************************************************************

already known.

Guillermo

On Wed, 6 Aug 2025 at 01:17, Volker Braun <vbrau...@gmail.com> wrote:

[Dima Pasechnik]

On Wed, Aug 6, 2025 at 4:41 PM Marc Culler <marc....@gmail.com> wrote:
>
> I am unable to build gp2c on a manylinux2014 docker image with this release. There are 3210 errors of the form "multiple definition of X" starting with:
>
> [spkg-install] /opt/rh/devtoolset-10/root/usr/libexec/gcc/x86_64-redhat-linux/10/ld: context.o:(.bss+0x0): multiple definition of `debug_stack'; gp2c.o:(.bss+0x0): first defined here
> [spkg-install] /opt/rh/devtoolset-10/root/usr/libexec/gcc/x86_64-redhat-linux/10/ld: context.o:(.bss+0x8): multiple definition of `typemax'; gp2c.o:(.bss+0x8): first defined here

please check whether the upgrade to gp2c 0.0.14 helps:
https://github.com/sagemath/sage/pull/40552
(the upgrade that should have been done as soon as we switched to pari 2.17)

Dima

>
> - Marc
>
>
> On Tuesday, August 5, 2025 at 6:17:49 PM UTC-5 Volker Braun wrote:
>>
>> As always, you can get the latest beta version from the "develop" git branch. Alternatively, the self-contained source tarball is at http://www.sagemath.org/download-latest.html
>>
>> 4a2dac04955 (tag: 10.7.rc1, github/develop) Updated SageMath version to 10.7.rc1
>> bcdffce78b7 gh-40519: typo + guava
>> 94fe540d332 (tag: 10.7.rc0) Updated SageMath version to 10.7.rc0
>

> --
> 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 sage-release...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/sage-release/e0957cda-c67b-46f6-92af-dd891ba0ae40n%40googlegroups.com.

[Marc Culler]

I will check that, but I suspect it is a compiler issue.

I was able to get it to build by adding -fcommon to CFLAGS.  Apparently gcc 10, was the first version of gcc to make -fno-common be the default, and later versions may handle it in a way which allows gp2c to declare external variables in a header file which is included multiple times and has no guard.  Who knows, maybe

version 0.0.14 uses guards against multiple includes.

But I am seeing other issues that look like they are compiler issues.  The meataxe spkg also did not build, and a fix was to delete the word inline from a function definition in window.c.  It seems that gcc 10 does not always create a symbol for an inline function, so an inline function defined in a library  is not accessible to modules which link against the library.

I guess gcc 10 may be too old for sage.  But it does work if no optional packages are enabled.

- Marc 

[Dima Pasechnik]

Isn't it time to drop manylinux2014 (PEP 599)?
It is based on EOLed CentOS 7, and we don't support Python 3.7 and early 3.8/9, anyway, so what's the point?


<https://github.com/pypa/manylinux>

As far as gp2c specifically, we can if needed add flags into its spkg-install (and upgrade, still)

Dima

[Marc Culler]

The file sage/src/bin/sage-python seems to have disappeared in 10.7.rc1.  This breaks the installation of the sage-environment package, among other things.

- Marc

On Tuesday, August 5, 2025 at 6:17:49 PM UTC-5 Volker Braun wrote:

[G. M.-S.]

This file was there on SageMath 10.7.beta9, but no more on SageMath 10.7.rc0.

I can confirm that

% ./configure --enable-sagemath-environment

% make

fails with

  [sagemath_environment-10.7.rc1]   [spkg-install] error: [Errno 2] No such file or directory: 'bin/sage-python'

Guillermo

[Jan Groenewald]

Indeed

https://github.com/sagemath/sage/commit/c4f7b06a43c72f09df743772ff8f9ff00dcbf97b#commitcomment-163324918

--

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 sage-release...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/sage-release/CANnG18-7ebrTNnTdmimNtLpqhyvcs3ZogVnMw2NDi5sJHneswg%40mail.gmail.com.

[Dima Pasechnik]

what are the uses of the sagemath-environment spkg? why is it needed for anything?

[G. M.-S.]

Hi Dima.

I do not know the answer, but IMHO if it is available it should work.

BTW, I wonder whether you could reword your questions so that they would appear friendlier?

Thanks,

Guillermo

[Marc Culler]

The sagemath_environment package is a dependency of sagemath_bliss, sagemath_categories, sagemath_coxeter3, sagemath_meataxe, sagemath_objects, sagemath_repl, sagemath_sirocco, and sagemath_tdlib.

I am not the person to ask about why that is the case.  But I am surprised to learn that none of those packages get tested in a release candidate.

- Marc

You received this message because you are subscribed to a topic in the Google Groups "sage-release" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sage-release/e4wFGGJ9vME/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sage-release...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/sage-release/3D750982-2C9C-49E1-BA4A-9B9F3072E1D6%40gmail.com.

[Jan Groenewald]

Hi

https://github.com/pipedream/sage/tree/develop/pkgs/sagemath-environment

It provides a small, fundamental subset of the modules of the Sage library ("sagelib", sagemath-standard), providing the connection to the system and software environment. It also includes the sage script for launching the Sage REPL and accessing various developer tools (see sage --help).

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

Regards,

Jan

To view this discussion visit https://groups.google.com/d/msgid/sage-release/CALcZXRHaABs%2B6pYEE42tvViuA_-n2Apvh%2BGjMUR%2BBx3y%3DutpDg%40mail.gmail.com.

[Dima Pasechnik]

On Fri, Aug 8, 2025 at 11:08 AM Marc Culler <marc....@gmail.com> wrote:
>
> The sagemath_environment package is a dependency of sagemath_bliss, sagemath_categories, sagemath_coxeter3, sagemath_meataxe, sagemath_objects, sagemath_repl, sagemath_sirocco, and sagemath_tdlib.
>
> I am not the person to ask about why that is the case. But I am surprised to learn that none of those packages get tested in a release candidate.

the spkgs bliss, coxeter3, meataxe, sirocco, and tdlib are tested.
These sagemath_* wrappers are not, as they aren't needed.

Dima

> To view this discussion visit https://groups.google.com/d/msgid/sage-release/CALcZXRHaABs%2B6pYEE42tvViuA_-n2Apvh%2BGjMUR%2BBx3y%3DutpDg%40mail.gmail.com.

[Marc Culler]

I think that the move to replace "sage/local/bin/sage-python"  by "/usr/bin/env python3" contains a serious conceptual flaw.  It is based on an assumption which is frequently false.  The assumption is:

* Every user running sage will always have activated the same virtual environment which was used to build sage before running it.

It is very common, even among users who are not developers, to have more than one version of python installed on one's system.  It is not reasonable to expect a user with multiple versions of python to always remember to activate the python they used to build sage before running sage.  I am quite certain that will fail to happen regularly, and will produce a large number of issues and messages sent to sage-support.

A better design would be for sage to record the python installation which was used to build it, and for the sage script to ensure that the build python is first in the user's path when sage is started up.  This would help, but is not a panacea.  If someone deletes the python that they used to build sage, say because they just installed a newer version of python, they will destroy their sage.  (Yes, this is more likely for macOS and conda users, and would not affect non-conda linux users if only you could guarantee that those users always use the python version that comes with their distro.  But you cannot guarantee that.  After all, anyone capable of building sage is also capable of building python, and it is not at all unreasonable to do that, for example because a user wants to be working with the current version of python.)

Of course the set of issues above has a large intersection with the set of issues that led to sage having a python spkg in the first place.  It would be wise to address them before removing the python spkg.

To view this discussion visit https://groups.google.com/d/msgid/sage-release/CAAg%3Dp_06rWhP2GLVSGC%2B_61O6MRemJHVisNQrupHkF4kyHEZ2A%40mail.gmail.com.

[Marc Culler]

On Fri, Aug 8, 2025 at 11:50 AM Dima Pasechnik <dim...@gmail.com> wrote:

the spkgs bliss, coxeter3, meataxe, sirocco, and tdlib are tested.

I guess it depends on what you mean by "tested".  Those packages depend on sage_environment.  They cannot be built if the build of sage_environment fails.  So if testing includes checking that they build, then they evidently were not tested before the release.

- Marc

[Dima Pasechnik]

On Fri, Aug 8, 2025 at 11:56 AM Marc Culler <marc....@gmail.com> wrote:
>
> On Fri, Aug 8, 2025 at 11:50 AM Dima Pasechnik <dim...@gmail.com> wrote:
>
>> the spkgs bliss, coxeter3, meataxe, sirocco, and tdlib are tested.
>
>
> I guess it depends on what you mean by "tested". Those packages depend on sage_environment.

They don't - you are mixing up the listed above spkgs with their
sagemath_*-wrappers.
E.g.

$ cat build/pkgs/sirocco/dependencies
mpfr

> They cannot be built if the build of sage_environment fails. So if testing includes checking that they build, then they evidently were not tested before the release.
> - Marc
>

> --
> 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 sage-release...@googlegroups.com.

> To view this discussion visit https://groups.google.com/d/msgid/sage-release/CALcZXREck6P18U94xS2jE1LfF6DCS_605mdATo%2BKVN1XofHSNg%40mail.gmail.com.

[Marc Culler]

On Fri, Aug 8, 2025 at 12:10 PM Dima Pasechnik <dim...@gmail.com> wrote:

On Fri, Aug 8, 2025 at 11:56 AM Marc Culler <marc....@gmail.com> wrote:
>
> On Fri, Aug 8, 2025 at 11:50 AM Dima Pasechnik <dim...@gmail.com> wrote:
>
>> the spkgs bliss, coxeter3, meataxe, sirocco, and tdlib are tested.
>
>
> I guess it depends on what you mean by "tested".  Those packages depend on sage_environment.

They don't - you are mixing up the listed above spkgs with their
sagemath_*-wrappers.
E.g.

$ cat build/pkgs/sirocco/dependencies
mpfr

What I have been doing is to use options like  "--enable-sirocco" when I run configure. I have been using those options for as many optional packages as possible. You seem to be saying that those options force installation of a "wrapper" which depends on sage_environment.  So what am I supposed to do instead of using the --enable-X option if I want to build and install an optional package X without installing its "wrapper"?  (And what is the functional difference between having a "wrapper" and not having one?)

- Marc

[Dima Pasechnik]

On Fri, Aug 8, 2025 at 11:50 AM Marc Culler <marc....@gmail.com> wrote:
>
> I think that the move to replace "sage/local/bin/sage-python" by "/usr/bin/env python3" contains a serious conceptual flaw. It is based on an assumption which is frequently false. The assumption is:
>
> * Every user running sage will always have activated the same virtual environment which was used to build sage before running it.
>

that's not quite correct - e.g. if you have Sage installed in
site-packages (either the system-wide one, as it the case with Linux
distros shipping sagemath, or the user's one) of your system-wide
python3, then no venv is needed.

This is the default scenario, and anything else ought to be dealt with
by sagemath packagers for particular systems, e.g. said Linux distros,
or Conda (which is a popular environment to run all sorts of Python
things, sagemath included).
We don't want to shove a pre-cooked special sagemath venv down users'
throats - I don't think I can name a Python package which does this
(apart from SageMath).

> It is very common, even among users who are not developers, to have more than one version of python installed on one's system. It is not reasonable to expect a user with multiple versions of python to always remember to activate the python they used to build sage before running sage. I am quite certain that will fail to happen regularly, and will produce a large number of issues and messages sent to sage-support.
>
> A better design would be for sage to record the python installation which was used to build it, and for the sage script to ensure that the build python is first in the user's path when sage is started up. This would help, but is not a panacea. If someone deletes the python that they used to build sage, say because they just installed a newer version of python, they will destroy their sage. (Yes, this is more likely for macOS and conda users, and would not affect non-conda linux users if only you could guarantee that those users always use the python version that comes with their distro. But you cannot guarantee that.
After all, anyone capable of building sage is also capable of building
python, and it is not at all unreasonable to do that, for example
because a user wants to be working with the current version of
python.)

Building a fully working Python and the associated tooling is not
easy, given how close they are to the OS and the security subsystems.
That's why SageMath should not be doing it.

>
> Of course the set of issues above has a large intersection with the set of issues that led to sage having a python spkg in the first place. It would be wise to address them before removing the python spkg.

Python spkg is mostly a historic artifact, it sits there to bite
users once in a while, and serves no useful purpose today.
(just as these sagemath_* packages are). By the way, please feel free to review
https://github.com/sagemath/sage/pull/40460 (removal of zlib spkg) -
which is the next step towards removal of Python spkg.

> To view this discussion visit https://groups.google.com/d/msgid/sage-release/CALcZXRHPOye7EWx0J466KQMhNzOaKsHsyhboLv-4BL-YJ3d4hw%40mail.gmail.com.

[Dima Pasechnik]

On Fri, Aug 8, 2025 at 12:38 PM Marc Culler <marc....@gmail.com> wrote:
>
> On Fri, Aug 8, 2025 at 12:10 PM Dima Pasechnik <dim...@gmail.com> wrote:
>>
>> On Fri, Aug 8, 2025 at 11:56 AM Marc Culler <marc....@gmail.com> wrote:
>> >
>> > On Fri, Aug 8, 2025 at 11:50 AM Dima Pasechnik <dim...@gmail.com> wrote:
>> >
>> >> the spkgs bliss, coxeter3, meataxe, sirocco, and tdlib are tested.
>> >
>> >
>> > I guess it depends on what you mean by "tested". Those packages depend on sage_environment.
>>
>> They don't - you are mixing up the listed above spkgs with their
>> sagemath_*-wrappers.
>> E.g.
>>
>> $ cat build/pkgs/sirocco/dependencies
>> mpfr
>>
>
> What I have been doing is to use options like "--enable-sirocco" when I run configure. I have been using those options for as many optional packages as possible. You seem to be saying that those options force installation of a "wrapper" which depends on sage_environment.

No, I am saying the opposite. I am saying that --enable-sirocco etc
have nothing to do with sagemath_sirocco etc wrappers.
sagemath_* are basically a failed modularisation attempt, and are dead
wood as far as I am concerned.

Dima

[Marc Culler]

OK.  I found the configure option which triggered the install of sage_environment:  I had "--enable-sagemath_sirocco".

I will remove that since you say it is not needed.  Nonetheless, that option is listed as a valid option when one runs "configure --help",   So it should not produce a build failure.

This is what configure --help says:

--enable-sagemath_sirocco={no|if_installed (default)|yes}enable build and use of the optional package Sage: Open Source
                          Mathematics Software: Certified root continuation with sirocco

                         * package info: ./sage -info sagemath_sirocco

- Marc

--
You received this message because you are subscribed to a topic in the Google Groups "sage-release" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sage-release/e4wFGGJ9vME/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sage-release...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/sage-release/CAAWYfq1%2BG022NEp3nXPCLF8OCNSkftMs09ZZz9%2BuDmqxT-Xf0g%40mail.gmail.com.

[Dima Pasechnik]

On Fri, Aug 8, 2025 at 1:13 PM Marc Culler <marc....@gmail.com> wrote:
>
> OK. I found the configure option which triggered the install of sage_environment: I had "--enable-sagemath_sirocco".
>
> I will remove that since you say it is not needed. Nonetheless, that option is listed as a valid option when one runs "configure --help", So it should not produce a build failure.

Sorry, I spoke too soon. It should not be needed, but something fails
in the process of building the sirocco cython extension module
(when built in the classical non-meson way, which is still the default)

$ ./sage
┌────────────────────────────────────────────────────────────────────┐
│ SageMath version 10.7.rc1, Release Date: 2025-08-05 │
│ Using Python 3.13.5. Type "help()" for help. │
└────────────────────────────────────────────────────────────────────┘
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃ Warning: this is a prerelease version, and it may be unstable. ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
sage: import sage.libs.sirocco
---------------------------------------------------------------------------
ImportError Traceback (most recent call last)
Cell In[1], line 1
----> 1 import sage.libs.sirocco

ImportError: /home/dima/software/sage/src/sage/libs/sirocco.cpython-313-x86_64-linux-gnu.so:
undefined symbol: homotopyPath_mp_comps


Indeed, as I see, it's not linked against libsirocco (in local/lib) -
even though the latter is built.

$ ldd `find . -name sirocco.cpython-313-x86_64-linux-gnu.so`
linux-vdso.so.1 (0x00007f0bca624000)
libgmp.so.10 => /usr/lib64/libgmp.so.10 (0x00007f0bca542000)
libmpfr.so.6 => /usr/lib64/libmpfr.so.6 (0x00007f0bca482000)
libc.so.6 => /usr/lib64/libc.so.6 (0x00007f0bca296000)
/lib64/ld-linux-x86-64.so.2 (0x00007f0bca626000)

$ ls -l local/lib/*siro*
lrwxrwxrwx 1 dima dima 19 Aug 8 13:39 local/lib/libsirocco.so ->
libsirocco.so.0.0.0
lrwxrwxrwx 1 dima dima 19 Aug 8 13:39 local/lib/libsirocco.so.0
-> libsirocco.so.0.0.0
-rwxr-xr-x 1 dima dima 847592 Aug 8 13:39 local/lib/libsirocco.so.0.0.0

A quick way to fix it might be to add a pkg-config .pc file to
facilitate its discovery
(at least a similar spkg, braiding, works for me, as it has the latter in place)

Dima

> 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 sage-release...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/sage-release/CALcZXRHHPViXqt5bqUOtmC7%2BFE6VmATromwxH23YWe4G1jAnFA%40mail.gmail.com.

[Antonio Rojas]

El viernes, 8 de agosto de 2025 a las 21:45:42 UTC+2, Dima Pasechnik escribió

ImportError: /home/dima/software/sage/src/sage/libs/sirocco.cpython-313-x86_64-linux-gnu.so:
undefined symbol: homotopyPath_mp_comps

That symbol is not mangled, which means the sirocco extension was wrongly compiled as C instead of C++. This was fixed for meson in https://github.com/sagemath/sage/pull/40369 but apparently is also affecting the setuptools build now  (which is strange in view of 

 https://github.com/sagemath/sage/blob/10.7.rc1/src/sage/libs/sirocco.pyx#L3 )

[Marc Culler]

In case it is relevant ...

After restoring src/bin/sage-python,  and without reconfiguring, I was able to build and install sagemath_environment and sagemath_sirocco and successfully complete my build of sage.  With that build I am able to import sage.libs.sirocco.

- Marc

[G. M.-S.]

FWIW, I have just tried (on macOS 15.6)

./configure --enable-bliss --enable-coxeter3 --enable-meataxe --enable-sirocco --enable-tdlib

and then

make

and

make ptestlong

both succeed.

Guillermo

[Enrique Artal]

I cited this issue in https://groups.google.com/g/sage-release/c/9wOnB1csEqo/m/bVr2OUhEAQAJ and it is apparently solved in https://github.com/sagemath/sage/pull/40526. In this PR I commented the problem with sirocco libraries when enabling sirocco but not sagemath_sirocco (I do not know if it does affect to the other xxx in sagemath_xxx).

I did not get the error in Dima's message, but computations depending on sirocco failed due to the missing library. 

If I correctly understand Antonio Rojas' message, this problem does not affect meson builds, but honestly I failed trying to build sagemath with meson using the instructions. I can retry and show the error messages. 

Enrique.

[Dima Pasechnik]

For me,  using --enable-sagemath_sirocco switch results in a very broken sage, it crashes on startup. So the classic build just doesn't seem to work for sirocco sage interface, full stop.

it's not documented, but meson build of sagelib works at ./sage --buildsh prompt.
However, to get sirocco interface built correctly, one might need
<https://github.com/sagemath/sage/pull/40555>

[Jan Groenewald]

Hi Marc,

Even more relevant, does it build with this (and bin/sage-python NOT restored):

https://github.com/sagemath/sage/pull/40526/commits/93c7de0b5fc7991d82cbf2b1d755a3e7113b1791

And does everything work as expected?

Regards.

Jan

On Fri, 8 Aug 2025 at 22:43, Marc Culler <marc....@gmail.com> wrote:

--

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 sage-release...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/sage-release/8afb1f23-0b41-43b4-9a08-5ac6623c51a3n%40googlegroups.com.