Re: A small note on the portability of cmake
От
Tom Lane
Тема
Re: A small note on the portability of cmake
Дата
Msg-id
25135.1547997353@sss.pgh.pa.us
Ответ на
Re: A small note on the portability of cmake (Andres Freund)
Список
Дерево обсуждения
A small note on the portability of cmake Tom Lane <tgl@sss.pgh.pa.us>
Re: A small note on the portability of cmake Jesse Zhang <sbjesse@gmail.com>
Re: A small note on the portability of cmake Andres Freund <andres@anarazel.de>
Re: A small note on the portability of cmake Tom Lane <tgl@sss.pgh.pa.us>
Re: A small note on the portability of cmake Andres Freund <andres@anarazel.de>
Re: A small note on the portability of cmake Tom Lane <tgl@sss.pgh.pa.us>
Re: A small note on the portability of cmake Andres Freund <andres@anarazel.de>
Andres Freund 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
В списке pgsql-hackers по дате отправления
От: Amit Kapila
Дата: