Обсуждение: Building on S390
Hi, I spend some time trying to figure out why PostgreSQL builds on S390-Linux, but Postgres-XC doesn't. Well at least this holds for the Debian packages. So far I haven't figured it out. However, it appears to me that the build should fail for both. I'm not an S390 expert by any means, but I was told that S390 requires -fPIC and the build failure in the Debian package of XC came from a stray -fpic that was used together with -fPIC. But alas the PostgreSQL build has both as well. Anyway, I changed src/makefiles/Makefile.linux to include ifeq "$(findstring s390,$(host_cpu))" "s390" CFLAGS_SL = -fPIC else before setting CFLAGS_SL = -fpic et voila XC builds just fine on S390. So I wonder shouldn't we use -fPIC instead of -fpic for S390 in general? Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Michael Meskes <meskes@postgresql.org> writes:
> I spend some time trying to figure out why PostgreSQL builds on
> S390-Linux, but Postgres-XC doesn't. Well at least this holds for the Debian
> packages. So far I haven't figured it out. However, it appears to me that the
> build should fail for both. I'm not an S390 expert by any means, but I was told
> that S390 requires -fPIC and the build failure in the Debian package of XC came
> from a stray -fpic that was used together with -fPIC. But alas the PostgreSQL
> build has both as well.
I think this is probably nonsense. I spent ten years maintaining Postgres
for Red Hat, and I never saw any such failure on s390 in their packages.
If -fpic weren't good enough for shared libraries on s390, how'd any of
those builds get through their regression tests?
It may well be that *mixing* -fpic and -fPIC is a bad idea, but I'd say
that points to an error in something XC is doing, because the core
Postgres build doesn't use -fPIC anywhere for Linux/s390, AFAICS.
Furthermore, if we change that convention now, we're going to increase
the risk of such mixing failures for other people.
regards, tom lane
On Fri, Nov 22, 2013 at 11:27:45AM -0500, Tom Lane wrote: > I think this is probably nonsense. I spent ten years maintaining Postgres > for Red Hat, and I never saw any such failure on s390 in their packages. > If -fpic weren't good enough for shared libraries on s390, how'd any of > those builds get through their regression tests? You've got a point here. > It may well be that *mixing* -fpic and -fPIC is a bad idea, but I'd say > that points to an error in something XC is doing, because the core > Postgres build doesn't use -fPIC anywhere for Linux/s390, AFAICS. I actually only compared to the Debian build which *does* have -fPIC and indeed it seems it adds -fPIC unconditionally. But then the PostgreSQL package works flawlessly which obviously points to XC for the problem. I give you that. > Furthermore, if we change that convention now, we're going to increase > the risk of such mixing failures for other people. Sure, but if this a bug we should. I'm not saying it is, I simply don't know. The thread is starting with my email here http://lists.debian.org/debian-s390/2013/10/msg00008.html and the reply said: It uses -fpic instead of -fPIC. No, I'm not shortening that email reply here. :) Checking the Debian logs it appears that all calls use *both* which seems to do the right thing. And yes, it appears there is a change in XC that makes it break. But still, I would think there has to be a correct set of options. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Michael Meskes <meskes@postgresql.org> writes:
> On Fri, Nov 22, 2013 at 11:27:45AM -0500, Tom Lane wrote:
>> Furthermore, if we change that convention now, we're going to increase
>> the risk of such mixing failures for other people.
> Sure, but if this a bug we should. I'm not saying it is, I simply don't know.
Well, *if* it's a bug in core PG then we should do something about it,
but at the moment there's no evidence of that. What seems the most
likely theory here is that the Debian maintainer has broken their package
with an ill-considered patch. We can't take responsibility for other
people's hacks.
regards, tom lane
On 11/22/13, 12:41 PM, Michael Meskes wrote: > Checking the Debian logs it appears that all calls use *both* which seems to do > the right thing. And yes, it appears there is a change in XC that makes it > break. But still, I would think there has to be a correct set of options. According to the Debian build logs, postgres-xc compiles the entire backend with -fPIC. Not sure what sense that makes.
On Fri, Nov 22, 2013 at 8:51 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
On 11/22/13, 12:41 PM, Michael Meskes wrote:According to the Debian build logs, postgres-xc compiles the entire
> Checking the Debian logs it appears that all calls use *both* which seems to do
> the right thing. And yes, it appears there is a change in XC that makes it
> break. But still, I would think there has to be a correct set of options.
backend with -fPIC. Not sure what sense that makes.
Debian policy is to always use -fPIC
IIRC -fpic is good enough as long as the total size of the library is below some limit. I'm not sure precisely what this size is that has to be below the limit but if I recall correctly it's something you have no way to determine in advance for a general purpose library. So Debian decided long long ago to just use -fPIC always.
--
greg
Greg Stark <stark@mit.edu> writes:
> On Fri, Nov 22, 2013 at 8:51 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
>> According to the Debian build logs, postgres-xc compiles the entire
>> backend with -fPIC. Not sure what sense that makes.
> Debian policy is to always use -fPIC
> IIRC -fpic is good enough as long as the total size of the library is below
> some limit. I'm not sure precisely what this size is that has to be below
> the limit but if I recall correctly it's something you have no way to
> determine in advance for a general purpose library. So Debian decided long
> long ago to just use -fPIC always.
Well, in that case they did a really crappy job of applying that policy to
their Postgres packages, because it sure sounds like there's still some
-fpic switches laying about in their builds. But in any case, that
seems to me like a pretty brain-dead policy (hint: if you need -fPIC,
you'll get build failures that tell you so), so I feel no need to adopt
it for standard Postgres builds.
regards, tom lane
On Fri, 2013-11-22 at 23:32 +0000, Greg Stark wrote: > According to the Debian build logs, postgres-xc compiles the > entire > backend with -fPIC. Not sure what sense that makes. > > > Debian policy is to always use -fPIC My point is, they compile the *backend* as position-independent code. The backend is not a shared library. Maybe it is in Postgres-XC? But at least this makes their build process significantly different, so it's doubtful that this is a PG-proper issue.
Peter Eisentraut <peter_e@gmx.net> writes:
> On Fri, 2013-11-22 at 23:32 +0000, Greg Stark wrote:
>> Debian policy is to always use -fPIC
> My point is, they compile the *backend* as position-independent code.
> The backend is not a shared library. Maybe it is in Postgres-XC? But
> at least this makes their build process significantly different, so it's
> doubtful that this is a PG-proper issue.
Note that that's not an unreasonable decision in itself, if it's done
pursuant to some distro policy that daemons should run with ASLR enabled.
(Right before I left Red Hat, we were looking into building PG with -fPIE
for that reason. It didn't happen yet because of a kernel bug[1], but
it will eventually.)
But there's too many moving parts here for us to know exactly what's going
wrong without more evidence. The only thing that *is* pretty clear is
that the failure is not with the stock PG build anyway, so changing the
properties of the stock build sounds like the wrong response. Personally
I'd think it is the job of the Debian package maintainer to determine why
this is breaking.
regards, tom lane
[1] https://bugzilla.redhat.com/show_bug.cgi?id=952946
On Sat, 2013-11-23 at 11:49 -0500, Tom Lane wrote: > > My point is, they compile the *backend* as position-independent > code. > > The backend is not a shared library. Maybe it is in Postgres-XC? > But > > at least this makes their build process significantly different, so > it's > > doubtful that this is a PG-proper issue. > > Note that that's not an unreasonable decision in itself, if it's done > pursuant to some distro policy that daemons should run with ASLR > enabled. Right. False alarm.