Opened 6 years ago

Closed 6 years ago

#14172 closed defect (fixed)

mpir-2.6.0.p0 fails to build on Intel "Core" and Pentium4 Prescott CPUs

Reported by: tmonteil Owned by: GeorgSWeber
Priority: major Milestone: sage-5.9
Component: build Keywords: mpir spkg ABI standard Intel Core Pentium4 Prescott
Cc: leif, jpflori, jhpalmieri, kcrisman Merged in: sage-5.9.beta2
Authors: Leif Leonhardy Reviewers: Thierry Monteil, Jean-Pierre Flori
Report Upstream: Completely fixed; Fix reported upstream Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Description (last modified by tmonteil)

The build of sage 5.7 stops during the build of the mpir-2.6.0.p0 package.

spkg/logs/mpir-2.6.0.p0.log is pasted at http://paste.debian.net/237529/

The problem seems related to some 32-bit architecture:

Building a 32-bit version of MPIR.
Building MPIR with the C++ interface and (also) static libraries.
** Building with "fat binary" support for 32-bit CPUs **
[...]
configure: error: ABI=32 is not among the following valid choices: standard
Error configuring MPIR (with CFLAGS unset).

The machine is running Debian wheezy, Linux 3.2.0-4-686-pae #1 SMP Debian 3.2.35-2 i686 GNU/Linux

I used the following sage variables :

  • SAGE_FAT_BINARY='yes'
  • SAGE_BINARY_BUILD='yes'
  • SAGE_CHECK="yes"
  • MAKE="make -j2"

Exporting ABI='standard' globally (see http://ask.sagemath.org/question/1713/error-installing-package-mpir-240p6) allows the mpir spkg to be built but then gap-4.5.7.p3 cannot be built since it also uses the ABI variable for which the value 'standard' does not make sense (it only accepts ABI=32 or ABI=64).


Just for completeness: The previous spkg (and of course also vanilla MPIR 2.6.0) failed in exactly the same way when configured on (or with [MPIR_CONFIGURE=]--host=)prescott-pc-linux-gnu:

...
using ABI="standard"
      CC="gcc -std=gnu99"
      CFLAGS="-O2"
      CPPFLAGS=""
      CXX="g++"
      CXXFLAGS="-O2"
      MPN_PATH="  generic"
...

The new spkg also fixes this.


New spkg: http://boxen.math.washington.edu/home/leif/Sage/spkgs/mpir-2.6.0.p1.spkg

md5sum: 6e65bb989b0e5513371a35447b43b0da mpir-2.6.0.p1.spkg

Now patches acinclude.m4, configure.in, and configure.

(Changes now committed, and bug report and patches submitted upstream, too.)

mpir-2.6.0.p1 (Leif Leonhardy, February 27th 2013)

  • #14172: MPIR 2.6.0 (but also older versions) fails to configure on Intel "Core" CPUs (expecting ABI to be "standard" rather than "32", which is just one symptom). (Similar for Pentium4 Prescott.) Add patch (core-prescott-configure.patch) fixing acinclude.m4, configure.in, and the generated configure, rebased to the patches we apply in advance. Patch(es) have been submitted upstream.

Attachments (15)

mpir-2.6.0.p0-p1.diff (8.8 KB) - added by leif 6 years ago.
Diff between the .p1 and the .p0. For reference / review only.
cpuinfo (1.4 KB) - added by tmonteil 6 years ago.
2.6.0.p0_config.log (6.4 KB) - added by tmonteil 6 years ago.
2.6.0.p0_mpir-2.6.0.p0.log (6.0 KB) - added by tmonteil 6 years ago.
2.6.0.p0-ABI32_config.log (6.4 KB) - added by tmonteil 6 years ago.
2.6.0.p0-ABI32_mpir-2.6.0.p0.log (6.0 KB) - added by tmonteil 6 years ago.
2.6.0.p1_config.log (206.7 KB) - added by tmonteil 6 years ago.
2.6.0.p1_mpir-2.6.0.p1.log (547.9 KB) - added by tmonteil 6 years ago.
2.6.0.p1-ABI32_config.log (206.7 KB) - added by tmonteil 6 years ago.
2.6.0.p1-ABI32_mpir-2.6.0.p1.log (547.8 KB) - added by tmonteil 6 years ago.
2.6.0.p1-FAT_config.log (203.8 KB) - added by tmonteil 6 years ago.
2.6.0.p1-FAT_mpir-2.6.0.p1.log (633.3 KB) - added by tmonteil 6 years ago.
2.6.0.p1-FAT-ABI32_config.log (203.8 KB) - added by tmonteil 6 years ago.
2.6.0.p1-FAT-ABI32_mpir-2.6.0.p1.log (633.3 KB) - added by tmonteil 6 years ago.
config.guess (18 bytes) - added by tmonteil 6 years ago.

Change History (43)

comment:1 Changed 6 years ago by leif

  • Cc leif added
  • Keywords ABI 32 added

comment:2 Changed 6 years ago by leif

Could you attach spkg/build/mpir-2.6.0.p0/src/config.log (of a failed build)?

What does spkg/build/mpir-2.6.0.p0/src/config.guess give?

comment:3 follow-up: Changed 6 years ago by leif

Also /proc/cpuinfo might be interesting.

comment:4 Changed 6 years ago by leif

For reference, this is the current logic (originally for MPIR 2.4.0):

    Linux)
        # MPIR fails to build on 32-bit operating systems running on
        # 64-bit CPUs if CFLAGS happen to contain '-m32' and ABI is
        # *not* set, so we set it here if necessary:
        # (Cf. http://groups.google.com/group/mpir-devel/browse_thread/thread/46ccdc5dfc3485cd#)
        # Note: This code snippet could in principle be moved out of the
        #       Linux branch, but since we already set ABI for other
        #       OSs above (and print an according message), it's here.
        if [ -z "$ABI" ]; then
            echo "int main(){return 0;}" > foo.c
            # Try building and running a 64-bit executable:
            # (Building usually succeeds even on 32-bit systems, unless e.g. a 32-bit
            # CPU is explicitly selected by CFLAGS, while running does not.)
            if $CC $CFLAGS $CFLAG64 -o foo foo.c 2>/dev/null && ./foo 2>/dev/null; then
                # We can run 64-bit executables.
                # Setting ABI=64 shouldn't be necessary, but shouldn't hurt either.
                echo "Building a 64-bit version of MPIR."
                case "`uname -m`" in
                    ppc64) ABI=mode64;;
                    *)     ABI=64
                esac
            elif $CC $CFLAGS $CFLAG32 -o foo foo.c 2>/dev/null && ./foo 2>/dev/null; then
                # We're on a 32-bit OS which cannot run 64-bit executables.
                echo "Building a 32-bit version of MPIR."
                ABI=32
            else
                # It seems the compiler does not support -m32 nor -m64 (e.g.
                # GCC on Itanium rejects both); do not set ABI at all.
                echo "Your compiler does not support '$CFLAG32' nor '$CFLAG64'.  Leaving ABI unset."
            fi
            rm -f foo foo.c
        fi
        ;; # Linux

If only MPIR (2.6.0) requires ABI=standard (rather than ABI=32, or left empty/unset), one should presumably only set it for building MPIR:

$ unset ABI # (or set it to "32" on 32-bit operating systems running on a 64-bit CPU)
$ make -k # continue as far as possible
$ env ABI=standard ./sage -i spkg/standand/mpir-2.6.0.p0.spkg
$ make # build the rest

That way (not globally setting ABI=standard) shouldn't cause problems with other spkgs (such as GAP).

We'll see whether we can tweak spkg-install (or patch MPIR's configure) to not require this manual intervention, although [from a previous thread on a similar problem]

On Dec 24, 1:51 am, Bill Hart <goodwillh...@googlemail.com> wrote:
> I agree with William's synopsis. You definitely have 64 bit hardware,
> but a 32 bit OS. It's not that your hardware is "old". I was just
> wrong about that. We support much older hardware than Core 2's!
>
> Note that you will get an approximately 2x speedup of much
> mathematical software if you upgrade your linux to a 64 bit linux. So
> it is worth considering.

(SCNR.)

comment:5 Changed 6 years ago by leif

  • Summary changed from mpir-2.6.0.p0 fails to build on 32-bit architecure to mpir-2.6.0.p0 fails to build on Intel "Core" CPU running 32-bit Linux

comment:6 Changed 6 years ago by leif

The problem seems to be an upstream bug in MPIR 2.6.0, specifically on Intel Core (not Core2 or Core i7) processors, or, more precisely, shows up if config.guess yields core-* (probably only in conjunction with a 32-bit [Linux] OS, not sure right now).

comment:7 Changed 6 years ago by leif

  • Keywords standard Intel Core added; 32 removed
  • Report Upstream changed from N/A to Reported upstream. Developers acknowledge bug.
  • Summary changed from mpir-2.6.0.p0 fails to build on Intel "Core" CPU running 32-bit Linux to mpir-2.6.0.p0 fails to build on Intel "Core" CPUs

It doesn't seem to matter whether the OS is 32- or 64-bit, it's just core-* that doesn't allow ABI=32 nor ABI=64.

Note that (on core-*) with ABI=standard, the generic C implementation is chosen, which is odd.

comment:8 in reply to: ↑ 3 Changed 6 years ago by leif

Replying to leif:

Also /proc/cpuinfo might be interesting.

Thierry, could you paste the output of cat /proc/cpuinfo?

Also, do you happen to have the MPIR build log from Sage 5.6 on the same machine? (It seems the actual bug had been present in MPIR 2.4.0 and probably older releases as well, so we're curious what has changed inbetween -- probably the output of MPIR's config.guess.)

comment:9 follow-up: Changed 6 years ago by tmonteil

Here are the files.

I will see if i can found a log for the sage 5.6 build somewhere.

Note that is is sometimes good to be able to build a 32-bits sage system on a 64-bits machine. For example, i need this when building sage for a live USB key that aims to boot on a widest range of machines.

comment:10 in reply to: ↑ 9 Changed 6 years ago by leif

Replying to tmonteil:

Here are the files.

Thanks.

Sorry, I meant the output of running config.guess (you uploaded the file itself), but I guess it is just core-pc-linux-gnu. (Its output would also be interesting for MPIR 2.4.0, although I doubt it'll differ.)


I will see if i can found a log for the sage 5.6 build somewhere.

If you still have the Sage 5.6 installation (but not the logs in spkg/logs/), you could try reinstalling MPIR 2.4.0 with ./sage -f -s spkg/standard/mpir-2.4.0.p6.spkg. (-s keeps the spkg build directory, where the source code (including config.guess) and config.log are located, even if no error occurred during the installation.)


Note that is is sometimes good to be able to build a 32-bits sage system on a 64-bits machine. For example, i need this when building sage for a live USB key that aims to boot on a widest range of machines.

Yes. Some also prefer 32-bit versions for virtual machines (on 64-bit machines).

The safest way to produce (32-bit) binary dists is still to create them natively, on old machines. (E.g., ECM_CONFIGURE=--disable-sse2 is currently necessary for Pentium III and some older CPUs, which I only noticed while actually building on a Pentium III ...)

comment:11 Changed 6 years ago by tmonteil

  • Description modified (diff)

The output of running config.guess is indeed core-pc-linux-gnu (as well as on the mpir-2.4.0.p6.spkg).

Now, looking back at the logs of the sage-5.6 build, it seems that i built it on a more recent machine (though the live USB key with 32-bit OS was the same). Sorry for having missing that (i am currently oscillating between two different locations every two weeks).

Running ./sage -f -s spkg/standard/mpir-2.4.0.p6.spkg on the older machine does the same bug.

comment:12 Changed 6 years ago by leif

  • Authors set to Leif Leonhardy
  • Description modified (diff)
  • Status changed from new to needs_review

comment:13 Changed 6 years ago by leif

Thierry, could you give this preliminary spkg a try on your Intel Core machine?

Especially without SAGE_FAT_BINARY=yes, and ABI either unset or set to 32.

(SAGE_FAT_BINARY=yes should also work; you could of course try that as well, but the former is more important / interesting.)

And attach the resulting spkg log(s) here...

Thanks.

P.S.: If you're going to rebuild Sage or other spkgs depending on it with that, you should copy the spkg into $SAGE_ROOT/spkg/standard/. (You can use env SAGE_UPGRADING=yes make after doing so, in order to rebuild all dependent spkgs as well, although this is likely to take quite some time.)

comment:14 in reply to: ↑ description Changed 6 years ago by leif

Replying to leif:

mpir-2.6.0.p1 (Leif Leonhardy, February 26th 2013)

  • #14172: MPIR 2.6.0 (but also older versions) fails to configure on Intel "Core" CPUs (expecting ABI to be "standard" rather than "32", which is just a symptom). (Similar for Pentium4 Prescott.) We currently only patch (the generated) configure (after another patch to it and its source files has been applied), rather than [also] aclocal.m4 and configure.in.

s/aclocal.m4/acinclude.m4/

Last edited 6 years ago by leif (previous) (diff)

comment:15 follow-up: Changed 6 years ago by leif

[Note to myself:] I'll upload a slightly fixed spkg (also patching acinclude.m4 and configure.in laterTM, presumably tomorrow. (I missed some places when manually patching [just] configure, but these are minor I thinkTM.)

Changed 6 years ago by leif

Diff between the .p1 and the .p0. For reference / review only.

comment:16 in reply to: ↑ 15 Changed 6 years ago by leif

  • Description modified (diff)
  • Report Upstream changed from Reported upstream. Developers acknowledge bug. to Completely fixed; Fix reported upstream

Replying to leif:

[Note to myself:] I'll upload a slightly fixed spkg (also patching acinclude.m4 and configure.in laterTM, presumably tomorrow. (I missed some places when manually patching [just] configure, but these are minor I thinkTM.)

Done. Note: New spkg also has a new name (-preliminary dropped).

Last edited 6 years ago by leif (previous) (diff)

comment:17 Changed 6 years ago by leif

  • Description modified (diff)
  • Keywords Pentium4 Prescott added
  • Summary changed from mpir-2.6.0.p0 fails to build on Intel "Core" CPUs to mpir-2.6.0.p0 fails to build on Intel "Core" and Pentium4 Prescott CPUs

comment:18 Changed 6 years ago by leif

  • Description modified (diff)

comment:19 Changed 6 years ago by tmonteil

Hi Leif, i am back in Montpellier and the machine is still in Paris. I will try to find a similar machine here or ask someone to bring it back this week-end.

comment:20 Changed 6 years ago by tmonteil

  • Description modified (diff)

comment:21 Changed 6 years ago by leif

  • Cc jpflori added

Just in case you intend to support / fix the use of SAGE64 on Linux, it would be nice if you based your spkg on this one... ;-)

(And cc me if you open a ticket for that; I'll otherwise probably do so.)

Changed 6 years ago by tmonteil

Changed 6 years ago by tmonteil

Changed 6 years ago by tmonteil

Changed 6 years ago by tmonteil

Changed 6 years ago by tmonteil

Changed 6 years ago by tmonteil

Changed 6 years ago by tmonteil

Changed 6 years ago by tmonteil

Changed 6 years ago by tmonteil

Changed 6 years ago by tmonteil

Changed 6 years ago by tmonteil

Changed 6 years ago by tmonteil

Changed 6 years ago by tmonteil

Changed 6 years ago by tmonteil

comment:22 follow-up: Changed 6 years ago by tmonteil

Hi Leif, i found a Core Duo at the lab, and did the tests you asked on the same 32-bit OS, and all possibilities lead to a build without error with mpir-2.6.0.p1.spkg. FAT means that i exported SAGE_FAT_BINARY='yes', ABI32 means i exported ABI='32'. I also tried exporting SAGE_CHECK='yes' (with no other options exported) and the tests went fine.

comment:23 in reply to: ↑ 22 Changed 6 years ago by leif

Replying to tmonteil:

Hi Leif, i found a Core Duo at the lab, and did the tests you asked on the same 32-bit OS, and all possibilities lead to a build without error with mpir-2.6.0.p1.spkg. FAT means that i exported SAGE_FAT_BINARY='yes', ABI32 means i exported ABI='32'. I also tried exporting SAGE_CHECK='yes' (with no other options exported) and the tests went fine.

So do we have a positive review?

comment:24 follow-up: Changed 6 years ago by tmonteil

  • Cc jhpalmieri kcrisman added
  • Reviewers set to Thierry Monteil, ...

All tests passed on Core Duo, so it is OK for me. It could be nice to have it tested on some prescott cpu as well. Also, i let someone who is used in maintaining this spkg to check whether the patch is ok on the code side and give a positive review.

comment:25 in reply to: ↑ 24 Changed 6 years ago by leif

Replying to tmonteil:

All tests passed on Core Duo, so it is OK for me. It could be nice to have it tested on some prescott cpu as well. Also, i let someone who is used in maintaining this spkg to check whether the patch is ok on the code side and give a positive review.

Ping...

(Yesterday again someone reported running into this on sage-release.)

comment:26 follow-up: Changed 6 years ago by jpflori

  • Reviewers changed from Thierry Monteil, ... to Thierry Monteil, Jean-Pierre Flori
  • Status changed from needs_review to positive_review

Looks fine and build on a my (non problematic) system.

Just a little remark, I think you should tag the commit yourself as this is automatically done by Jeroen's scripts, though I think they are smart enough to realize you did it, so no worry.

comment:27 in reply to: ↑ 26 Changed 6 years ago by leif

Thanks for the review.

Replying to jpflori:

Just a little remark, I think you should tag the commit yourself as this is automatically done by Jeroen's scripts, though I think they are smart enough to realize you did it, so no worry.

I prefer tagging the changesets myself (and I'd appreciate if others did as well -- some do); doing so makes it easier to base spkgs on previous ones which haven't been merged yet (otherwise tags may even be missing).

The merger script shouldn't do anything with spkgs unless necessary, i.e., it should only perform sanity checks, and in case some of these fail, automagically modify the spkg if appropriate (which includes adding a missing revision tag).

comment:28 Changed 6 years ago by jdemeyer

  • Merged in set to sage-5.9.beta2
  • Resolution set to fixed
  • Status changed from positive_review to closed
Note: See TracTickets for help on using tickets.