Thread: FullTransactionId changes are causing portability issues

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

I wrote:
> 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
>> ---

On looking closer, the fix is simple and matches what we've done
elsewhere: transam.h needs to have "#ifndef FRONTEND" to protect
its static inline function from being compiled into frontend code.

So the disturbing thing here is that we no longer have any active
buildfarm members that can build HEAD but have the won't-elide-
unused-static-functions problem.  Clearly we'd better close that
gap somehow ... anyone have an idea about how to test it better?

            regards, tom lane