FullTransactionId changes are causing portability issues

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: FullTransactionId changes are causing portability issues
Date: 2019-05-22 13:56:07
Message-ID: 27054.1558533367@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: buildfarm-members pgsql-hackers

Our Solaris packager reports that 12beta1 is failing to build for him
on some Solaris variants:

> The link failure is:

> ---
> Undefined first referenced
> symbol in file
> ReadNextFullTransactionId pg_checksums.o
> ld: fatal: symbol referencing errors. No output written to pg_checksums
> ---

> Now, ReadNextFullTransactionId() is implemented in
> src/backend/access/transam/varsup.c but I cannot see varsop.o being
> included in any of the libraries pg_checksum is linked against
> (libpgcommon.a and libpgport.a).

> When I check the pg_checksum.o I find that it references
> ReadNextFullTransactionId on the platforms that fail but not where it
> doesn't. The failed platforms are all sparc variants plus 64-bit x86
> on Solaris 11.

> The compiler used in Sun Studio 12u1, very old and and I can try to
> upgrade and see if that helps.
> [ it didn't ]

I'm a bit mystified why we did not see this problem in the buildfarm,
especially since we have at least one critter (damselfly) running an
OpenSolaris variant. Nonetheless, it sure looks like a "somebody
was sloppy about frontend/backend separation" problem.

Fix ideas anyone? I think we need to not only solve the immediate
problem (which might just take an #ifndef FRONTEND somewhere) but
also close the testing gap so we don't get blindsided like this
again.

regards, tom lane

Responses

Browse buildfarm-members by date

  From Date Subject
Next Message Tom Lane 2019-05-22 14:48:08 Re: FullTransactionId changes are causing portability issues
Previous Message Andrew Dunstan 2019-04-04 22:54:39 Re: PostgreSQL Buildfarm Client Release 10

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2019-05-22 14:39:41 Re: "long" type is not appropriate for counting tuples
Previous Message Tom Lane 2019-05-22 13:46:19 Re: pg_dump throwing "column number -1 is out of range 0..36" on HEAD