configure: Handle the case of SAGE_LOCAL = a system directory with gcc better

[mkoeppe]

(split out from #30845)

git grep SAGE_LOCAL src/sage shows that there are still a few leftover places in the Sage library that hardcode SAGE_LOCAL as the directory where some executables etc. are found, notably gap.

In some settings, this forces us to set SAGE_LOCAL to a system location when ideally it should ideally be unset (as in distribution packaging). In particular, in the (experimental) set up of Conda for Sage developers described in https://wiki.sagemath.org/Conda, we would set SAGE_LOCAL to CONDA_PREFIX.

We adjust the configure script for this situation.

CC: @isuruf @tobiasdiez @kiwifb @orlitzky @dimpase

Component: build: configure

Author: Matthias Koeppe

Branch/Commit: ce6f8fd

Reviewer: Dima Pasechnik

Issue created by migration from https://trac.sagemath.org/ticket/33361

[mkoeppe]

Branch: u/mkoeppe/configure__handle_the_case_of_sage_local___a_system_directory_with_gcc_better

[mkoeppe]

Author: Matthias Koeppe

[mkoeppe]

Commit: ce6f8fd

[mkoeppe]

New commits:

d547541	build/pkgs/gcc/spkg-configure.m4: Handle the case of SAGE_LOCAL = a system directory with gcc better
ce6f8fd	build/pkgs/gcc/spkg-configure.m4: Handle the case of SAGE_LOCAL = a system directory with gcc better (fixup)

[kiwifb]

comment:4

It is difficult for me to comment on that part of the configure script from the point of view of sage-on-gentoo since I don't use it at all.

[mkoeppe]

comment:6

Let's get this in please

[dimpase]

comment:7

is there an easy obvious way to test this?

[mkoeppe]

comment:8

"Conda for Sage developers" instructions at https://wiki.sagemath.org/Conda?

[mkoeppe]

comment:9

Or use configure --prefix=/usr in a discardable VM/container

[dimpase]

comment:10

Replying to @mkoeppe:

Or use configure --prefix=/usr in a discardable VM/container

just tried in a Docker container, and ran into

config.status: /usr/lib64 is not a symlink, see Trac #19782
config.status: error: Cannot perform incremental update, run "make distclean && make"

not sure if this is a bug for this branch.

[mkoeppe]

comment:11

Not a bug.

[mkoeppe]

comment:12

Use a different distro for testing that does not have this

[dimpase]

comment:13

I'd say it is a bug in this case. Trying now with

--- a/configure.ac
+++ b/configure.ac
@@ -530,7 +530,7 @@ AC_CONFIG_COMMANDS(mkdirs,
         if test -d "$SAGE_LOCAL/lib64"; then
             if test ! -L "$SAGE_LOCAL/lib64"; then
                 AC_MSG_NOTICE([[$SAGE_LOCAL/lib64 is not a symlink, see Trac #19782]])
-                AC_MSG_ERROR([[Cannot perform incremental update, run "make distclean && make"]])
+             dnl   AC_MSG_ERROR([[Cannot perform incremental update, run "make distclean && make"]])
             fi
         else
             AC_MSG_NOTICE([[creating symbolic link lib64 -> lib]])

[dimpase]

comment:14

Replying to @mkoeppe:

Not a bug.

it ought to work if we don't error out here in case of --prefix=/usr.

[mkoeppe]

comment:15

... but we do not want to support this configuration for users, it's just a quick way for you to test the ticket. The actual use case is installation into a conda environment, #30845.

[dimpase]

comment:16

ok, it works

[dimpase]

Reviewer: Dima Pasechnik

[dimpase]

comment:17

by the way, do we know how to report opensuse-tumbleweed bugs? There gphelp, a part of pari/gp, does not work.
(it doesn't seem to work on the recent homebrew, too)

[mkoeppe]

comment:18

Thank you!

[mkoeppe]

comment:19

Replying to @dimpase:

by the way, do we know how to report opensuse-tumbleweed bugs?

Yes, https://bugzilla.opensuse.org; so far no competent response to an issue that I reported for #33153 though

[vbraun]

Changed branch from u/mkoeppe/configure__handle_the_case_of_sage_local___a_system_directory_with_gcc_better to ce6f8fd