Consider building with -fPIC by default on Linux, due to conflict with RTLD_DEEPBIND

[topolarity]

Bug report

Bug description:

Shared libraries that depend on GCC's libgomp v13 fail to load in Python if the executable was linked without -fPIC:

$ cat test.c
int add(int a, int b) { return a + b; }
$ gcc --version
gcc (GCC) 13.0.1 20230416 (experimental)
$ gcc test.c -shared -fPIC -o libtest.so -Wl,-rpath $(dirname $(which gcc))/../lib64 -lgomp
$ python3.11
Python 3.11.0rc1 (main, Aug 12 2022, 10:02:14) [GCC 11.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import ctypes, os
>>> ctypes.CDLL("./libtest.so", os.RTLD_DEEPBIND)
[1]    123469 segmentation fault  python3.11

The problem here is that libgomp.so ends up accessing an uninitialized copy of a symbol in libc (specifically environ).

When Python is linked without -fPIC, the linker introduces a copy of environ in the executable .bss section. This copy is what is used by the executable and most libraries, but libraries loaded with RTLD_DEEPBIND do not resolve to it. They instead encounter the original (uninitialized) symbol in libc, triggering this segfault.

See also https://stackoverflow.com/a/34074587 and https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111556, along with downstream issues JuliaLang/julia#53363 (comment) and conda-forge/ctng-compilers-feedstock#114

Note: Before GCC 13, libgomp did not access the environ symbol in libc so it wasn't sensitive to this kind of linker problem. However, since GCC 13, it does access this symbol and assumes that it has been initialized by libc.

CPython versions tested on:

3.11

Operating systems tested on:

Linux