Re: [HACKERS] [PATCH] relocation truncated to fit: citus build failure on s390x

Andres Freund <andres@anarazel.de>

From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Christoph Berg <myon@debian.org>, Jason Petersen <jason@citusdata.com>, pgsql-pkg-debian@postgresql.org, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2017-05-30T16:15:41Z
Lists: pgsql-hackers
On 2017-05-29 15:45:11 -0400, Tom Lane wrote:
> Christoph Berg <myon@debian.org> writes:
> > 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:
> 
> I wonder what the overhead is of using -fPIC when -fpic would be
> sufficient.  Whatever it is, the proposed patch imposes it on every
> shlib or extension, to accommodate one single extension that isn't
> even one we ship.

> Maybe this is small enough to not be something we need to worry about,
> but I'm wondering if we should ask citus and other large .so's to set
> some additional make flag that would cue usage of -fPIC over -fpic.

I think we can fix this easily enough in Citus, postgis, and whatever.
But it's not a particularly good user/developer experience, and
presumably is going to become more and more common. On x86 there
shouldn't be a difference in efficiency between the two, but some others
will see some.  Given that most distributions switched to building the
main executables with -fPIE anyway, to allow for ASLR, it seems unlikely
that the intra extension overhead is going to be very meaningful in
comparison.

Greetings,

Andres Freund


Commits

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