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

[mkoeppe]

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.

[mkoeppe]

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

---

New commits:

​749f83e	tox.ini: Add other archs supported by docker
​e941bd5	fixup for llocal
​2441fe9	tox.ini: Restructure docker image:tag construction, add multiarch for Linux Docker
​2f057cb	tox.ini: Add raspbian
​7f122bd	build/bin/write-dockerfile.sh: src/ext has moved and is no longer needed for the configure phase
​3972311	gfortran on 32bit: Configure for the same ABI as gcc

[mkoeppe]

Anyone interested in reviewing this?

[dimpase]

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

[git]

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

[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

[mkoeppe]

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

[mkoeppe]

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

[git]

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

​35711ae

Use gcc -print-target-triple for clang

[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)

[git]

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

​7847ee9

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

[git]

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

​dcdb8ce

Usee gcc -dumpmachine

[mkoeppe]

Tests at ​https://github.com/mkoeppe/sage/actions/runs/53297072

[mkoeppe]

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

Ready for review.

[git]

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

​c830344

Use gcc -dumpmachine

[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.

[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.

[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".

[git]

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

​c85c26f

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

[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?

[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.

[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).

[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.

[mkoeppe]

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

[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.

[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. These are pretty low return-on-investment scenarios, though. Feel free to set positive review if the CI and build bots are happy.

[mkoeppe]

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!