Skip to content
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

Flint fails to install with gmp from system #27708

Closed
timokau opened this issue Apr 21, 2019 · 11 comments
Closed

Flint fails to install with gmp from system #27708

timokau opened this issue Apr 21, 2019 · 11 comments

Comments

@timokau
Copy link
Contributor

timokau commented Apr 21, 2019

Trying to build sage using its own build system with gmp present results in:

Package 'flint' is currently not installed
No legacy uninstaller found for 'flint'; nothing to do
Configuring FLINT.
Invalid GMP directory

Flint fails to build. Looking into its configure script, it looks for GMP in /usr/local or whatever was passed as --with-gmp at configure time. However gmp is located in /usr, not /usr/local. Sage passes the contents of the SAGE_GMP_PREFIX variable to --with-gmp, but according to the install logs that environment variable is empty (while SAGE_GMP_INCLUDE is set correctly):

SAGE_EXTCODE=/home/timo/repos/sage/local/share/sage/ext
SAGE_GMP_INCLUDE=///usr/include
SAGE_GMP_PREFIX=
SAGE_LOCAL=/home/timo/repos/sage/local
SAGE_LOGS=/home/timo/repos/sage/logs/pkgs

CC: @embray @dimpase @slel @wbhart @zerline

Component: build: configure

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

@timokau timokau added this to the sage-8.8 milestone Apr 21, 2019
@embray
Copy link
Contributor

embray commented Apr 23, 2019

comment:1

Is this specifically on NIX or something? I don't have this problem on Cygwin or Linux.

@timokau
Copy link
Contributor Author

timokau commented Apr 23, 2019

comment:2

Possible of course, but this is in a bind mount specifically for building sage using its own build system. So I'd at least be a little surprised.

Does gmp happen to be located in /usr/local for you?

@embray
Copy link
Contributor

embray commented Apr 23, 2019

comment:3

Sage passes the contents of the SAGE_GMP_PREFIX variable to --with-gmp

I don't think that's quite accurate. Looking at the version of #27212 that was finally merged, flint is configured like:

./configure ... $SAGE_CONFIGURE_GMP ...

where $SAGE_CONFIGURE_GMP is a variable defined in src/bin/sage-env-config as

if [ -n "$SAGE_GMP_PREFIX" ]; then
    export SAGE_CONFIGURE_GMP="--with-gmp=$SAGE_GMP_PREFIX"
fi

That is, if $SAGE_GMP_PREFIX is empty then $SAGE_CONFIGURE_GMP should be undefined.

In any case, I can confirm that as you say, flint's hand-written configure script just always defaults its GMP_DIR variable to GMP_DIR=/usr/local (even if --prefix) is set to something else. This is buggy.

It's not normally a problem because the way it uses GMP_DIR, everything will still work if GMP can be picked up through the standard paths. But the configure script errors out with the error you reported if, say, /usr/local/lib does not exist.

I would say this is a bug in flint, but one we can possibly work around if need be. In the meantime you can try to work around it by setting the environment variable export FLINT_CONFIGURE=--with-gmp=/usr

@timokau
Copy link
Contributor Author

timokau commented Apr 23, 2019

comment:4

Thanks for investigating! Yes, /usr/local indeed doesn't exist. But why doesn't sage determine SAGE_GMP_PREFIX correctly?

@embray
Copy link
Contributor

embray commented Apr 24, 2019

comment:5

It does determine it "correctly" by not making any assumptions about it at all. All we know from autoconf is that a usable GMP is on the system. There's not necessarily any notion of a "GMP prefix" because for all we know the GMP headers could be /foo/include and the library in /bar/lib/x86_64-linux-gnu.

In other words, we don't make any assumptions about the system's filesystem layout or how it relates to where headers and libraries are found. We can only do that in certain narrow cases such as when using Sage SPKGs, in which case we have control over exactly where and how they're installed.

@timokau
Copy link
Contributor Author

timokau commented Apr 24, 2019

comment:6

Replying to @embray:

It does determine it "correctly" by not making any assumptions about it at all. All we know from autoconf is that a usable GMP is on the system.

How does it determine that if it doesn't locate it?

There's not necessarily any notion of a "GMP prefix" because for all we know the GMP headers could be /foo/include and the library in /bar/lib/x86_64-linux-gnu.

What is the purpose of sages SAGE_GMP_PREFIX, SAGE_GMP_INCLUDE then?

@embray
Copy link
Contributor

embray commented Apr 25, 2019

comment:7

Replying to @timokau:

Replying to @embray:

It does determine it "correctly" by not making any assumptions about it at all. All we know from autoconf is that a usable GMP is on the system.

How does it determine that if it doesn't locate it?

The same way most autoconf scripts determine this: If it can compile with #include <gmp.h> and link something containing symbols from libgmp with -lgmp then it works. The script itself doesn't have to know "where" those things come from as that depends on the toolchain and compiler/linker flags.

There's not necessarily any notion of a "GMP prefix" because for all we know the GMP headers could be /foo/include and the library in /bar/lib/x86_64-linux-gnu.

What is the purpose of sages SAGE_GMP_PREFIX, SAGE_GMP_INCLUDE then?

They are used specifically when using the gmp or mpir SPKGs from Sage in which case these do have meaningful values that need to be passed to other packages' configure scripts. See again #27212.

@embray
Copy link
Contributor

embray commented Jun 14, 2019

comment:8

As the Sage-8.8 release milestone is pending, we should delete the sage-8.8 milestone for tickets that are not actively being worked on or that still require significant work to move forward. If you feel that this ticket should be included in the next Sage release at the soonest please set its milestone to the next release milestone (sage-8.9).

@embray embray removed this from the sage-8.8 milestone Jun 14, 2019
@mkoeppe
Copy link
Contributor

mkoeppe commented Mar 20, 2020

comment:9

Possible dup: #28409

@mkoeppe
Copy link
Contributor

mkoeppe commented Mar 20, 2020

comment:10

This issue also surfaced at #29104 for homebrew

@mkoeppe
Copy link
Contributor

mkoeppe commented Dec 23, 2023

outdated

@mkoeppe mkoeppe closed this as not planned Won't fix, can't repro, duplicate, stale Dec 23, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants