Thread: [GENERAL] Using different GCC, CFLAGS, CCFLAGS and CPPFLAGS to compile Postgresand PostGIS?

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

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

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