Using different GCC, CFLAGS, CCFLAGS and CPPFLAGS to compile Postgres and PostGIS?
Hi,
I am wondering about this question for a while with no definite answer to
it, can someone explain me in detail to clear me out on the following
question :
What can go wrong or is it acceptable if I build Postgres from source with
let's say GCC 4.x.y and some specific CFLAGS, CPPFLAGS and CCFLAGS and when
I try to install an extension for Postgres such as PostGIS using a
different version of GCC lets say GCC 4.x.z with varying CFLAGS, CCFLAGS
and CPPFLAGS and if I follow the same process for other non-contrib
extensions? I want to know the theory behind this and it would serve me a
great help to understand the systems aspect of the process as well.
Thanks
On 2/1/2017 8:34 PM, postgres user wrote:
I am wondering about this question for a while with no definite answer
to it, can someone explain me in detail to clear me out on the
following question :What can go wrong or is it acceptable if I build Postgres from source
with let's say GCC 4.x.y and some specific CFLAGS, CPPFLAGS and
CCFLAGS and when I try to install an extension for Postgres such as
PostGIS using a different version of GCC lets say GCC 4.x.z with
varying CFLAGS, CCFLAGS and CPPFLAGS and if I follow the same process
for other non-contrib extensions? I want to know the theory behind
this and it would serve me a great help to understand the systems
aspect of the process as well.
the PGXS build process that most postgres extensions are built with
should use the same flags the postgres server was built with. minor
compiler version differences shouldn't matter, but major ones certainly
would. if the project doesn't use PGXS its harder to keep it all
straight, while remaining portable.
otherwise, your question is far too vague to be directly answerable.
given a nearly infinite number of combinations of ways of doing things
wrong, predicting whats going to happen in each case is futile.
--
john r pierce, recycling bits in santa cruz
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
postgres user <postgresuser1989@gmail.com> writes:
What can go wrong or is it acceptable if I build Postgres from source with
let's say GCC 4.x.y and some specific CFLAGS, CPPFLAGS and CCFLAGS and when
I try to install an extension for Postgres such as PostGIS using a
different version of GCC lets say GCC 4.x.z with varying CFLAGS, CCFLAGS
and CPPFLAGS and if I follow the same process for other non-contrib
extensions? I want to know the theory behind this and it would serve me a
great help to understand the systems aspect of the process as well.
You could certainly break things that way if you tried hard enough.
"Hard enough" would involve, say, selecting compiler flags that alter
ABI details like function calling conventions or struct packing rules.
Then the code in the extension would expect to call or be called
differently than the code in the core server expects to do it, or
would believe that structs declared in core server header files are
laid out differently than the code in the core server thinks, etc.
Using a different compiler would matter if it wasn't ABI-compatible with
the compiler used for the core code. Usually, vendor-supplied compilers
for different C variants are all configured to be ABI-compatible on a
given platform; but again you could break it if you tried hard enough,
like say using a home-built compiler that you'd configured randomly
differently from the platform's default compiler.
It would be more useful to ask about specific changes you want to make
in the compiler and flag choices (and explaining why you want to make
those specific changes wouldn't be a bad thing either).
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Also can you explain if I built Postgres from source on one platform lets
say RHEL_6 and deployed its artifacts like its binaries, libs and share on
a CentOS and tried building extensions against Postgres on CentOS are there
any dangers of doing that?
On Wed, Feb 1, 2017 at 8:34 PM, postgres user <postgresuser1989@gmail.com>
wrote:
Show quoted text
Hi,
I am wondering about this question for a while with no definite answer to
it, can someone explain me in detail to clear me out on the following
question :What can go wrong or is it acceptable if I build Postgres from source with
let's say GCC 4.x.y and some specific CFLAGS, CPPFLAGS and CCFLAGS and when
I try to install an extension for Postgres such as PostGIS using a
different version of GCC lets say GCC 4.x.z with varying CFLAGS, CCFLAGS
and CPPFLAGS and if I follow the same process for other non-contrib
extensions? I want to know the theory behind this and it would serve me a
great help to understand the systems aspect of the process as well.Thanks
postgres user <postgresuser1989@gmail.com> writes:
Also can you explain if I built Postgres from source on one platform lets
say RHEL_6 and deployed its artifacts like its binaries, libs and share on
a CentOS
In general I would not expect that to work. RHEL to CentOS is a special
case because they're really the same platform --- if it didn't work, you'd
have grounds to file a bug against the CentOS maintainers. But, say, RHEL
to Debian likely wouldn't work, and neither set of maintainers would
consider an ABI-compatibility complaint to be a valid bug.
and tried building extensions against Postgres on CentOS are there
any dangers of doing that?
Doesn't matter if the core system itself doesn't work, which it wouldn't
in cross-platform cases.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general