Building on S390

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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:

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.

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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]https://bugzilla.redhat.com/show_bug.cgi?id=952946, 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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers