Re: FullTransactionId changes are causing portability issues

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

> 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?

Ah-hah --- some study of the gcc manual finds that modern versions
of gcc have

`-fkeep-inline-functions'
     In C, emit `static' functions that are declared `inline' into the
     object file, even if the function has been inlined into all of its
     callers.  This switch does not affect functions using the `extern
     inline' extension in GNU C89.  In C++, emit any and all inline
     functions into the object file.

This seems to do exactly what we need to test for this problem.
I've confirmed that with it turned on, a modern platform finds
the ReadNextFullTransactionId problem with yesterday's sources,
and that everything seems green as of HEAD.

So, we'd obviously not want to turn this on for normal builds,
but could we get a buildfarm animal or two to use this switch?

			regards, tom lane