-
-
Notifications
You must be signed in to change notification settings - Fork 527
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix Singular configure so it accepts NTL installed in nonstandard locations #29335
Comments
comment:1
Singular's checks for GMP and FLINT are almost as bad, but because the check for the header file is commented out, it happens to accept the libraries that are accessible via CPPFLAGS and LDFLAGS. |
This comment has been minimized.
This comment has been minimized.
New commits:
|
Commit: |
Author: Matthias Koeppe |
comment:6
Those detections are a bit better in newer versions of singular, but still a bit off. My pull request to sanitize the new |
comment:7
Glad to hear that upstream accepts build cleanup patches! |
comment:8
The fix on this ticket works (see #29104 / https://github.com/mkoeppe/sage/runs/508693083) - but it turns out that homebrew's NTL is not suitable:
This is something that our |
This comment has been minimized.
This comment has been minimized.
comment:10
Ready for review |
comment:11
what's going on in Why one cannot just use |
comment:12
Making upstream singular configuration non-dodgy is beyond the scope of this ticket. |
comment:13
oops, sorry, I have not realised that's Singular's how about we just pass it what's Sage already knows about NTL headers, i.e. |
comment:14
The problem is that we do not really determine SAGE_NTL_PREFIX. It is empty if the system package is used. |
comment:15
(see ticket description) |
comment:16
Replying to @mkoeppe:
But we can, as we call AC_CHECK_HEADER, and it sets |
comment:17
ac_cv_header_NTL_ZZ_h=yes |
comment:18
OK, but we can use IMHO this way we don't have to patch Singular at all, right? Just pass the value, whatever it is. |
comment:19
I wouldn't consider use of this terrible macro an improvement. |
comment:20
In particular, reconstructing an install prefix from the location of a header file is NOT a good technical solution. |
comment:21
if you don't want a terrible macro, you can parse |
comment:22
Sorry, none of these are improvements over the simple patch. |
comment:23
OK. Upstream really needs to get this stuff fixed. |
Reviewer: Dima Pasechnik |
comment:24
Thanks. |
Changed branch from u/mkoeppe/always_find_sage_ntl_prefix_and_call_singular_configure_with_it to |
As observed in #29104, Singular's configure may fail to find NTL even if Sage finds a system NTL. It continues to build, but the result is broken.
The details:
NTL's
spkg-configure.m4
(from #27265/#27822) usesAC_CHECK_HEADER
/AC_LINK_IFELSE
/AC_RUN_IFELSE
and therefore is able to find NTL in an environment where the user has set CPPFLAGS and LDFLAGS accordingly.In that case, it sets
AC_SUBST(SAGE_NTL_PREFIX, [''])
Then
build/bin/sage-build-env-config.in
does:But Singular's
configure
(via itsm4/ntl-check.m4
) insists to find the headers inNTL_HOME_PATH
, which defaults toDEFAULT_CHECKING_PATH="/usr /usr/local /sw /opt/local"
, which can of course be quite wrong.On this ticket, we use a simple patch that modifies Singular's NTL detection code to make it similar to its GMP and FLINT detection codes.
An alternative solution would be to always provide the --with-ntl=PREFIX option to Singular.
We should also make it an error if Singular's configure cannot find NTL.
See also: #25993 - Upgrade Singular
CC: @dimpase @embray @kiwifb @mwageringel @antonio-rojas
Component: build: configure
Author: Matthias Koeppe
Branch/Commit:
50f62c7
Reviewer: Dima Pasechnik
Issue created by migration from https://trac.sagemath.org/ticket/29335
The text was updated successfully, but these errors were encountered: