Re: [PATCH] relocation truncated to fit: citus build failure on s390x
Christoph Berg <myon@debian.org>
From: Christoph Berg <myon@debian.org>
To: Andres Freund <andres@anarazel.de>, Jason Petersen <jason@citusdata.com>, pgsql-pkg-debian@postgresql.org, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2017-05-29T15:58:50Z
Lists: pgsql-hackers
Re: To Andres Freund 2016-04-28 <20160428080824.GA22412@msg.df7cb.de> > > I'm not clear why citus triggers this, when other extensions don't? > > Maybe it's simply because citus.so is bigger than all the other > extension .so files: > > -fpic > Generate position-independent code (PIC) suitable for use > in a shared library, if supported for the target machine. > Such code accesses all constant addresses through a global > offset table (GOT). The dynamic loader resolves the GOT > entries when the program starts (the dynamic loader is not > part of GCC; it is part of the operating system). If the > GOT size for the linked executable exceeds a machine- > specific maximum size, you get an error message from the > linker indicating that -fpic does not work; in that case, > recompile with -fPIC instead. (These maximums are 8k on > the SPARC and 32k on the m68k and RS/6000. The 386 has no > such limit.) > > Position-independent code requires special support, and > therefore works only on certain machines. For the 386, GCC > supports PIC for System V but not for the Sun 386i. Code > generated for the IBM RS/6000 is always > position-independent. > > When this flag is set, the macros "__pic__" and "__PIC__" > are defined to 1. > > -fPIC > If supported for the target machine, emit > position-independent code, suitable for dynamic linking and > avoiding any limit on the size of the global offset table. > This option makes a difference on the m68k, PowerPC and > SPARC. > > Position-independent code requires special support, and > therefore works only on certain machines. > > When this flag is set, the macros "__pic__" and "__PIC__" > are defined to 2. > > This doesn't mention s390(x), but citus.so 382952 bytes (on amd64) is > well beyond the 8k/32k limits mentioned above. > > PostgreSQL itself links correctly on s390x: > ... -I/usr/include/mit-krb5 -fPIC -pie -I../../../../src/include > > I'm not an expert in compiler flags, but it seems to me CFLAGS_SL is > wrong on s390(x) in Makefile.port, it should use -fPIC like sparc. After talking to a s390x Debian porter, -fPIC is the correct flag to use. The quoted patch made the previously failing builds for citus and pglogical (which have larger-than-average .so files) on s390x succeed (and the sparc64 case still works): --- a/src/makefiles/Makefile.linux +++ b/src/makefiles/Makefile.linux @@ -5,7 +5,8 @@ export_dynamic = -Wl,-E rpath = -Wl,-rpath,'$(rpathdir)',--enable-new-dtags DLSUFFIX = .so -ifeq "$(findstring sparc,$(host_cpu))" "sparc" +# Enable -fPIC to avoid "relocation truncated to fit" linker errors +ifneq "$(filter sparc% s390%,$(host_cpu))" "" CFLAGS_SL = -fPIC else CFLAGS_SL = -fpic The patch was made against 9.6; I'd opt to include it in master and the back branches. https://buildd.debian.org/status/logs.php?pkg=citus&arch=s390x https://buildd.debian.org/status/logs.php?pkg=pglogical&arch=s390x Christoph
Commits
-
Always use -fPIC, not -fpic, when building shared libraries with gcc.
- cee7238de58f 9.3.18 landed
- a378b9bc287d 9.2.22 landed
- 8d9b4fe01b5e 9.6.4 landed
- 894ce0e97ab1 9.4.13 landed
- 68938ab8ea0e 9.5.8 landed
- e9a3c047a5fc 10.0 landed