From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Jesse Zhang <sbjesse(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: A small note on the portability of cmake |
Date: | 2019-01-20 15:15:53 |
Message-ID: | 25135.1547997353@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2019-01-19 23:39:37 -0800, Jesse Zhang wrote:
>> Atomic ops (compare-and-exchange) might be a harder dependency to shed
>> for libuv. Does the fallback onto compiler intrinsics
>> (__sync_val_compare_and_swap, or on GCC 4.7+,
>> __atomic_compare_exchange_n) not work here?
Nope, the failure manifests as
/usr/local/lib/libuv.so.1.0: undefined reference to `__sync_val_compare_and_swap_4'
when some dependent package tries to use the library. So the build
failed to notice that the compiler intrinsics don't exist. (I was
using OpenBSD's packaging of libuv, which I guess doesn't bother
running any test cases during build.)
> HPPA doesn't hardware instructions for atomic ops other than
> test-and-set IIRC.
Indeed, the main reason why I'm interested in keeping this old dinosaur
going at all is that it is so different from other platforms in terms
of what we can assume about spinlocks and atomic ops. Keeps us honest.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Chapman Flack | 2019-01-20 16:06:09 | Re: PostgreSQL vs SQL/XML Standards |
Previous Message | Amit Kapila | 2019-01-20 14:54:50 | Re: possible deadlock: different lock ordering for heap pages |