Opened 2 years ago
Closed 2 years ago
#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: |
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 2 years ago by
- Branch set to u/mkoeppe/gfortran_on_32bit__configure_for_the_same_abi_as_gcc
comment:2 Changed 2 years ago by
- Cc vbraun added
- Commit set to 3972311748757b4795754b4f7d831ed2fccdfa1a
- Status changed from new to needs_review
comment:3 Changed 2 years ago by
- 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:5 follow-up: ↓ 13 Changed 2 years ago by
I don't know how to set up an environment where this change matters.
comment:6 Changed 2 years ago by
- Commit changed from 3972311748757b4795754b4f7d831ed2fccdfa1a to 7ae21c3f35718808ddbba90431097d18e3f95e7b
Branch pushed to git repo; I updated commit sha1. New commits:
7ae21c3 | Merge tag '9.1.beta7' into t/29241/gfortran_on_32bit__configure_for_the_same_abi_as_gcc
|
comment:7 Changed 2 years ago by
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 2 years ago by
The equivalent option with clang is gcc -print-target-triple
comment:9 Changed 2 years ago by
- Status changed from needs_review to needs_work
comment:10 Changed 2 years ago by
Well, on OS X building for i386 no longer works. But I'll add clang support just in case for FreeBSD.
comment:11 Changed 2 years ago by
- Commit changed from 7ae21c3f35718808ddbba90431097d18e3f95e7b to 35711aea44edb54e56b1c46ec6b09465fd4acc79
Branch pushed to git repo; I updated commit sha1. New commits:
35711ae | Use gcc -print-target-triple for clang
|
comment:12 Changed 2 years ago by
- Status changed from needs_work to needs_review
comment:13 in reply to: ↑ 5 Changed 2 years ago by
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)
comment:14 Changed 2 years ago by
- Commit changed from 35711aea44edb54e56b1c46ec6b09465fd4acc79 to 7847ee9dc264532c071b4930d022fb41512e8a10
Branch pushed to git repo; I updated commit sha1. New commits:
7847ee9 | build/pkgs/gfortran/spkg-build: Treat i[4-6]86 like i386
|
comment:15 Changed 2 years ago by
- Commit changed from 7847ee9dc264532c071b4930d022fb41512e8a10 to dcdb8cee9e31b937542e0f47d6f2d5d0d993dfbe
Branch pushed to git repo; I updated commit sha1. New commits:
dcdb8ce | Usee gcc -dumpmachine
|
comment:16 Changed 2 years ago by
comment:17 Changed 2 years ago by
This fixed the remaining platform centos-7-i386-minimal
.
Ready for review.
comment:18 Changed 2 years ago by
- Cc mjo added
comment:19 Changed 2 years ago by
- Commit changed from dcdb8cee9e31b937542e0f47d6f2d5d0d993dfbe to c830344820c40a8079d773a23c22378d10ce8e05
Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:
c830344 | Use gcc -dumpmachine
|
comment:20 follow-up: ↓ 21 Changed 2 years ago by
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: ↓ 22 Changed 2 years ago by
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: ↓ 24 Changed 2 years ago by
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 2 years ago by
- Commit changed from c830344820c40a8079d773a23c22378d10ce8e05 to c85c26f2beda594cfb6d8a5904ce7ecc39f28a18
Branch pushed to git repo; I updated commit sha1. New commits:
c85c26f | build/pkgs/gfortran/spkg-build: shell style fixes suggested by mjo
|
comment:24 in reply to: ↑ 22 ; follow-up: ↓ 25 Changed 2 years ago by
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 2 years ago by
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 2 years ago by
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 2 years ago by
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 2 years ago by
Simply because we cannot link 32bit & 64bit into one executable
comment:29 Changed 2 years ago by
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: ↓ 31 Changed 2 years ago by
- 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 2 years ago by
- 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 setsCC=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 2 years ago by
- 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
Tested on
docker-debian-buster-i386-minimal
, where the gfortran build now succeeds. Needs review.New commits:
tox.ini: Add other archs supported by docker
fixup for llocal
tox.ini: Restructure docker image:tag construction, add multiarch for Linux Docker
tox.ini: Add raspbian
build/bin/write-dockerfile.sh: src/ext has moved and is no longer needed for the configure phase
gfortran on 32bit: Configure for the same ABI as gcc