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

  1. Always use -fPIC, not -fpic, when building shared libraries with gcc.