#29241 closed defect (fixed)

gfortran installation on 32bit userland, 64bit kernel: Configure for the same ABI as gcc

Reported by: mkoeppe Owned by:
Priority: major Milestone: sage-9.1
Component: porting Keywords:
Cc: dimpase, tmonteil, vbraun, jhpalmieri, mjo Merged in:
Authors: Matthias Koeppe Reviewers: Michael Orlitzky
Report Upstream: N/A Work issues:
Branch: c85c26f (Commits, GitHub, GitLab) Commit: c85c26f2beda594cfb6d8a5904ce7ecc39f28a18
Dependencies: Stopgaps:

Status badges

Description

The i386-minimal targets have build errors compiling gfortran (see for example https://github.com/mkoeppe/sage/runs/463683795) because of ABI mismatch. These tests are running 32-bit distributions on a 64-bit kernel. gfortran tries to build native (64-bit) but that fails because the corresponding architecture files are missing.

Change History (32)

comment:1 Changed 19 months ago by mkoeppe

  • Branch set to u/mkoeppe/gfortran_on_32bit__configure_for_the_same_abi_as_gcc

comment:2 Changed 19 months ago by mkoeppe

  • Authors set to Matthias Koeppe
  • Cc vbraun added
  • Commit set to 3972311748757b4795754b4f7d831ed2fccdfa1a
  • Status changed from new to needs_review

Tested on docker-debian-buster-i386-minimal, where the gfortran build now succeeds. Needs review.


New commits:

749f83etox.ini: Add other archs supported by docker
e941bd5fixup for llocal
2441fe9tox.ini: Restructure docker image:tag construction, add multiarch for Linux Docker
2f057cbtox.ini: Add raspbian
7f122bdbuild/bin/write-dockerfile.sh: src/ext has moved and is no longer needed for the configure phase
3972311gfortran on 32bit: Configure for the same ABI as gcc

comment:3 Changed 19 months ago by mkoeppe

  • Summary changed from gfortran on 32bit: Configure for the same ABI as gcc to gfortran installation on 32bit userland, 64bit kernel: Configure for the same ABI as gcc

comment:4 Changed 19 months ago by mkoeppe

  • Cc jhpalmieri added

Anyone interested in reviewing this?

comment:5 follow-up: Changed 19 months ago by dimpase

I don't know how to set up an environment where this change matters.

comment:6 Changed 19 months ago by git

  • Commit changed from 3972311748757b4795754b4f7d831ed2fccdfa1a to 7ae21c3f35718808ddbba90431097d18e3f95e7b

Branch pushed to git repo; I updated commit sha1. New commits:

7ae21c3Merge tag '9.1.beta7' into t/29241/gfortran_on_32bit__configure_for_the_same_abi_as_gcc

comment:7 Changed 19 months ago by jhpalmieri

Will the gfortran spkg-install file ever be run on OS X?

$ gcc -print-multiarch
clang: error: unknown argument: '-print-multiarch'
clang: error: no input files

comment:8 Changed 19 months ago by mkoeppe

The equivalent option with clang is gcc -print-target-triple

comment:9 Changed 19 months ago by mkoeppe

  • Status changed from needs_review to needs_work

comment:10 Changed 19 months ago by mkoeppe

Well, on OS X building for i386 no longer works. But I'll add clang support just in case for FreeBSD.

comment:11 Changed 19 months ago by git

  • Commit changed from 7ae21c3f35718808ddbba90431097d18e3f95e7b to 35711aea44edb54e56b1c46ec6b09465fd4acc79

Branch pushed to git repo; I updated commit sha1. New commits:

35711aeUse gcc -print-target-triple for clang

comment:12 Changed 19 months ago by mkoeppe

  • Status changed from needs_work to needs_review

comment:13 in reply to: ↑ 5 Changed 19 months ago by mkoeppe

Replying to dimpase:

I don't know how to set up an environment where this change matters.

Tests ran at https://github.com/mkoeppe/sage/runs/493828325

Fixed: ubuntu-bionic-i386-minimal, ubuntu-eoan-i386-minimal, debian-buster-i386-minimal.

Remaining error: centos-7-i386-minimal (https://github.com/mkoeppe/sage/runs/493828336)

Last edited 19 months ago by mkoeppe (previous) (diff)

comment:14 Changed 19 months ago by git

  • Commit changed from 35711aea44edb54e56b1c46ec6b09465fd4acc79 to 7847ee9dc264532c071b4930d022fb41512e8a10

Branch pushed to git repo; I updated commit sha1. New commits:

7847ee9build/pkgs/gfortran/spkg-build: Treat i[4-6]86 like i386

comment:15 Changed 19 months ago by git

  • Commit changed from 7847ee9dc264532c071b4930d022fb41512e8a10 to dcdb8cee9e31b937542e0f47d6f2d5d0d993dfbe

Branch pushed to git repo; I updated commit sha1. New commits:

dcdb8ceUsee gcc -dumpmachine

comment:17 Changed 19 months ago by mkoeppe

This fixed the remaining platform centos-7-i386-minimal.

Ready for review.

comment:18 Changed 19 months ago by mkoeppe

  • Cc mjo added

comment:19 Changed 19 months ago by git

  • Commit changed from dcdb8cee9e31b937542e0f47d6f2d5d0d993dfbe to c830344820c40a8079d773a23c22378d10ce8e05

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

c830344Use gcc -dumpmachine

comment:20 follow-up: Changed 19 months ago by mjo

I'll have to take your word for it that this fixes the problem. Some implementation nitpicks:

ARCH=`$CC -dumpmachine 2>/dev/null || echo unknown`

The form $(command) should be preferred over backticks here (http://mywiki.wooledge.org/BashFAQ/082).

And if you explicitly want to call GCC here, shouldn't you use "gcc" instead of $CC?

    x86_64,i[3-6]86*)

Personally I would just write [3456] there. Ranges in globs are a bash extension, but more importantly they involve the system locale and collation, leading to rare problems that can be avoided by just listing the numbers you want to match.

comment:21 in reply to: ↑ 20 ; follow-up: Changed 19 months ago by mkoeppe

Replying to mjo:

I'll have to take your word for it that this fixes the problem.

The logs on the various machines are available at the links posted.

Some implementation nitpicks:

ARCH=`$CC -dumpmachine 2>/dev/null || echo unknown`

The form $(command) should be preferred over backticks here (http://mywiki.wooledge.org/BashFAQ/082).

OK will do.

And if you explicitly want to call GCC here, shouldn't you use "gcc" instead of $CC?

No, this needs to run the specific compiler that is configured!

    x86_64,i[3-6]86*)

Personally I would just write [3456] there. Ranges in globs are a bash extension, but more importantly they involve the system locale and collation, leading to rare problems that can be avoided by just listing the numbers you want to match.

OK will do.

comment:22 in reply to: ↑ 21 ; follow-up: Changed 19 months ago by mkoeppe

Replying to mkoeppe:

And if you explicitly want to call GCC here, shouldn't you use "gcc" instead of $CC?

No, this needs to run the specific compiler that is configured!

In particular, this is supposed to work also if CC is configured to be "gcc -m32".

comment:23 Changed 19 months ago by git

  • Commit changed from c830344820c40a8079d773a23c22378d10ce8e05 to c85c26f2beda594cfb6d8a5904ce7ecc39f28a18

Branch pushed to git repo; I updated commit sha1. New commits:

c85c26fbuild/pkgs/gfortran/spkg-build: shell style fixes suggested by mjo

comment:24 in reply to: ↑ 22 ; follow-up: Changed 19 months ago by mjo

Replying to mkoeppe:

In particular, this is supposed to work also if CC is configured to be "gcc -m32".

Ah, ok. I was thinking more along the lines of, what if CC is e.g. clang or icc?

comment:25 in reply to: ↑ 24 Changed 19 months ago by mkoeppe

Replying to mjo:

Replying to mkoeppe:

In particular, this is supposed to work also if CC is configured to be "gcc -m32".

Ah, ok. I was thinking more along the lines of, what if CC is e.g. clang or icc?

Well, clang supports the -dumpmachine option too.

I have not tested with icc; I don't know if Sage is known to build at all with this compiler.

comment:26 Changed 19 months ago by mkoeppe

There's some evidence (https://github.com/JuliaLang/julia/issues/9145) that icc supports this option too on Linux (but possibly not on macOS - which is not a problem because 32-bit builds are no longer supported; and the fallback to unknown should take care of it).

comment:27 Changed 19 months ago by mjo

My concern isn't about the -dumpmachine flag per se. We need to build gfortran with the same ABI as gcc, because gfortran tries to use headers from GCC and they won't be where gfortran expects them to be if the ABIs are mismatched. But if CC=clang, why should we insist that the ABI of clang and gfortran are the same? In that case, you still want to ensure that the ABIs of gfortran/gcc agree, not gfortran/clang.

comment:28 Changed 19 months ago by mkoeppe

Simply because we cannot link 32bit & 64bit into one executable

comment:29 Changed 19 months ago by mkoeppe

We need to build gfortran with the same ABI as the C compiler that is used, not some gcc that may be on the system.

comment:30 follow-up: Changed 19 months ago by mjo

  • Reviewers set to Michael Orlitzky

Ok, that makes sense. I was focusing on the bits/libc-header-start.h: No such file or directory errors. I guess we could still get build failures if GCC is 32-bit but someone has built a 64-bit clang and sets CC=clang. These are pretty low return-on-investment scenarios, though. Feel free to set positive review if the CI and build bots are happy.

comment:31 in reply to: ↑ 30 Changed 19 months ago by mkoeppe

  • Status changed from needs_review to positive_review

Replying to mjo:

Ok, that makes sense. I was focusing on the bits/libc-header-start.h: No such file or directory errors. I guess we could still get build failures if GCC is 32-bit but someone has built a 64-bit clang and sets CC=clang.

Right. In this situation, probably we would have to build the full gcc, possibly with bootstrapping.

These are pretty low return-on-investment scenarios, though.

I agree. If this ever becomes a problem, this can be fixed separately.

Feel free to set positive review if the CI and build bots are happy.

Thanks!

comment:32 Changed 19 months ago by vbraun

  • Branch changed from u/mkoeppe/gfortran_on_32bit__configure_for_the_same_abi_as_gcc to c85c26f2beda594cfb6d8a5904ce7ecc39f28a18
  • Resolution set to fixed
  • Status changed from positive_review to closed
Note: See TracTickets for help on using tickets.