Re: --with-llvm on 32-bit platforms?
От | Dmitry Mityugov |
---|---|
Тема | Re: --with-llvm on 32-bit platforms? |
Дата | |
Msg-id | 7a32d348a882199a035643f78e26f97a@postgrespro.ru обсуждение исходный текст |
Ответ на | Re: --with-llvm on 32-bit platforms? (Peter Eisentraut <peter@eisentraut.org>) |
Ответы |
Re: --with-llvm on 32-bit platforms?
|
Список | pgsql-hackers |
Peter Eisentraut wrote 2025-09-15 09:36: > On 05.09.25 13:32, Dmitry Mityugov wrote: >> Dmitry Mityugov писал(а) 2025-09-05 11:11: >>> Dmitry Mityugov писал(а) 2025-09-05 00:32: >>>> It seems that when I add --with-llvm flag to ./configure on any 32- >>>> bit platform that I have (Debian 12, Debian 13, Arch Linux), many >>>> tests invoked by `make check` fail, or, sometimes, hang forever. Is >>>> this a known problem? It's not critical to me, just wanted to know >>>> if I should abandon --with-llvm forever on such platforms. On 64-bit >>>> Linux platforms, both x86 and ARM, --with-llvm works fine. >>>> >>>> To reproduce, it's enough to: >>>> >>>> make distclean >>>> ./configure --with-llvm >>>> make -j23 -ks >>>> make check >>>> >>>> The last step is never successful to me, and, by the way, this can >>>> also be reproduced with clang: >>>> >>>> make distclean >>>> ./configure CC=clang CXX=clang++ --with-llvm CFLAGS=-msse2 >>>> make -j23 -ks >>>> make check >>>> >>>> Thanks in advance for your attention to this problem, or telling me >>>> this is not a problem at all >>> >>> One of the reasons I ask this question is that according to >>> f5d07085822a1 parameter --with-llvm is now mandatory in some cases, >>> but it seems it can't be used. >> >> By the way, when I rebuild REL_17_STABLE using the steps above (on >> Debian 13 32-bit is this matters) tests in `make check` pass, so it >> seems that something is broken in master. > > It seems plausible that this is related to commit 2a600a93c7b "Make > type Datum be 8 bytes wide everywhere.". I don't have any more > insights than that. Thanks for the hint. I did git bisect, and it seems that the first ‘bad’ commit is this: commit 2a600a93c7be5b0bf8cacb1af78009db12bc4857 Author: Tom Lane <tgl@sss.pgh.pa.us> Date: Wed Aug 13 16:35:06 2025 -0400 Make type Datum be 8 bytes wide everywhere. … I'll try to look further to understand what particular change in this commit is responsible for the problem. Thank you again
В списке pgsql-hackers по дате отправления: