| 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: | Whole Thread | Raw Message | 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
| 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 |
| 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 |