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