Re: failing to build preproc.c on solaris with sun studio
От | Andres Freund |
---|---|
Тема | Re: failing to build preproc.c on solaris with sun studio |
Дата | |
Msg-id | 20220807010927.5mjyzotxznuwsjla@awork3.anarazel.de обсуждение исходный текст |
Ответ на | Re: failing to build preproc.c on solaris with sun studio (Noah Misch <noah@leadboat.com>) |
Ответы |
Re: failing to build preproc.c on solaris with sun studio
|
Список | pgsql-hackers |
On 2022-08-06 17:59:54 -0700, Noah Misch wrote: > On Sat, Aug 06, 2022 at 05:43:50PM -0700, Andres Freund wrote: > > Sure, we can hack around it in some way. But if we need such hackery to > > compile postgres with a compiler, what's the point of supporting that > > compiler? It's not like sunpro provides with awesome static analysis or such. > > To have a need to decide that, PostgreSQL would need to grow preproc.o such > that it causes 55% higher RAM usage, and the sunpro buildfarm members extant > at that time would need to have <= 32 GiB RAM. I give a 15% chance of > reaching such conditions, and we don't gain much by deciding in advance. I'd > prefer to focus on decisions affecting more-probable outcomes. My point wasn't about the future - *today* a compile with normal settings doesn't work, on a machine with a reasonable amount of ram. Who does it help if one person can get postgres to compile with some applied magic - normal users won't. And it's not a cost free thing to support, e.g. I tried to build because solaris with suncc forces me to generate with_gnu_ld when generating a compatible Makefile.global for pgxs with meson.
В списке pgsql-hackers по дате отправления: