Support for --disable-giac

[orlitzky]

Giac is a PITA to have as a dependency:

• There's no public source repository
• There's no bug tracker
• There are no release announcements, new releases just show up in some random directory...
• If you can tell what is the latest release, because there's no coherent version scheme
• No one knows what's in the new releases, breaking changes show up in what appear to be minor versions
• The tarball is manually generated and often contains random files from the author's computer
• The test suite for every version fails on almost every machine
• Recent releases contain undefined behavior that is retained intentionally even though it crashes glibcxx
• The build emits hundreds of compiler warnings
• As a result of all of this, each release requires heavy patching (i.e. time & effort) even on "boring" systems
• But now I have a new computer that is not boring, and those compiler warnings weren't kidding, because giac segfaults all over the place
• So I can't use giac any more, and if Sage has a hard dependency on it, then I can't use Sage any more either

Fortunately it looks like it won't be too hard to make giac optional in Sage:

1. https://github.com/sagemath/sage/pull/38669
2. https://github.com/sagemath/sage/pull/38672
3. https://github.com/sagemath/sage/pull/38690
4. https://github.com/sagemath/sage/pull/38756
5. https://github.com/sagemath/sage/pull/38686 (not strictly required, but it conflicts with several "needs" tags)
6. https://github.com/sagemath/sage/pull/38770
7. Add the --disable-giac flag to ./configure
8. Figure out how to disable the building of sage.libs.giac when libgiac is not found

We lose a few integration examples in the doctests when the giac algorithm is skipped in favor of sympy, but that's about it.

[parisseb]

I wonder if it's really worth replying such an attack. For the records, there is a repository for giac source files inside geogebra git repo, changes are commented there. I do not maintain myself a repository. I copy the auto-generated tarballs when I build a binary deb package and it sets the version number. When I build a binary deb, I of course check my own regression tests (I have to make some times adjustements). I'm using glibcxx,without problems once some recent "features" are disabled (this is of course done by the configure script from giac if you don't patch it), because I do not want to modify working source code. If you want to report a bug, you can do it on Xcas forum.

If sagemath chooses to make giac optional, it might be a problem for some sage users, not for me. There are plenty of users of giac worldwide, either from ports I maintain myself or embedded in other applications. Bye!

[kiwifb]

Hi Parisse, I am going to guess that you refer to this repo https://github.com/geogebra/giac which is quite different from the source tarballs we can find on your site. It has a different build system and I am not sure what we build with it. If this is your official repo, it would be nice to know how it relates to your releases. Some of your latest source tarballs have come with arm objects and executables. Which kindly interferes with the build process because make does not know about the architecture of the object. The compile does generate a lot (understatement) of warnings. C++ standard are moving much faster than you do. But if you accept PRs we may be able to catch up on that. Disabling features and working source code. The end of that logic is usually not to update anything as much as possible. Which means developing in a specific, end of life, version of Linux in a Virtual Machine and exclusively distributing the application as containers produced on that machine - maybe I am too modern, virtual machine images would be safer. It means your application has now a lot in common with appliance such as dishwashers and washing machines (without IoT) - not necessarily a bad thing so long as we are clear about it.

[parisseb]

Geogebra has indeed it's own build system, but the source files and header files of giac are the same as in the giac tarball (except for the FLTK Xcas UI). The giac tarball is a unique source for the giac library and Xcas UI, that's the reason why it contains files relative to Xcas, like ARM32 firmwares port of Xcas for the Numworks calculators (Xcas can handle these calculators). There are a lot of warnings if you enable all warnings (like unsigned vs signed integers warnings), with the default flags I don't get much warnings (a few while compiling Xcas UI source files). If you have changes to propose, you can post them on Xcas forum (I believe you already have an account there). The best for me is a tarball with the changed files if there are many changes (I'll do the diff myself and merge within emacs), or just a diff for a small number of changes. I may have to reject some changes (or ifdef them), if they are not compatible with the many ports of giac (including all calculator ports with sometimes old compilers). Sorry I did not understand your last paragraph.

[dimpase]

4. Add # needs giac tags everywhere else

5. Add the --disable-giac flag to ./configure

6. Figure out how to disable the building of sage.libs.giac when libgiac is not found

just changing the package type to optional enables --disable-giac. So I'm going to do this, and then see which doctests fail, and tag them. Should be done then :-)

[orlitzky]

For the last step (disabling sage.libs.giac), meson will help in the short term, but for sage-the-distro I think we should move the entire folder into a separate sagemath-giac package. We can have it depend on sagemath-standard rather than -categories and -objects unless someone wants to adopt Matthias's PR.

[dimpase]

Frankly, I'd rather see the distributions spaghetti in a freezer or another suitable container. The objections to #38712 seem to stem from the old way(s) of building sagelib, and sagelib only. If you build sage-distro in the usual way, then #38712 pretty much does what's advertised.

With meson build, it should not be a problem, no need to do a deep dive into spaghetti, to produce more of it ?

[orlitzky]

Frankly, I'd rather see the distributions spaghetti in a freezer or another suitable container. The objections to #38712 seem to stem from the old way(s) of building sagelib, and sagelib only. If you build sage-distro in the usual way, then #38712 pretty much does what's advertised.

I think if you --disable-giac in #38712 and don't have giac installed, sagelib will fail to build because it still tries to link sage/libs/giac/* against libgiac (which isn't there). I haven't tried your branch recently but I did roughly the same thing and that was the big problem I ran into. Unless you can make sage/libs/giac go away somehow, you'll get build failures.

With meson build, it should not be a problem, no need to do a deep dive into spaghetti, to produce more of it ?

Yes meson will be a big help because it will skip compilation of sage/libs/giac if its dependencies (like libgiac) are not found. At that point there is no real problem for me. Still, I think there is some value to having sagemath-giac as a separate package:

• It keeps giac and sagelib from getting re-entangled
• You can upgrade one or the other independently (faster)
• It will fix the sage/libs/giac problem for non-meson builds in the meantime if it takes us a very long time to finish the meson migration. (In sagelib, we would rm -rf sage/libs/giac and then add sagemath-giac to build/pkgs as optional.)

[vbraun]

For the record, giac::zmakelinesplit consistently segfaults the Sage testsuite on the macos M2 buildbot. I could fix it but I don't even know against which repo.

+1 for having a way to disable giac

[parisseb]

Please post your fix proposal here as well as the command that raised the segfault (probably a gbasis). Thank you.

[vbraun]

I don't want to take over this issue, so I opened https://github.com/sagemath/sage/issues/38864 (for lack of an upstream bug tracker)