Re: failing to build preproc.c on solaris with sun studio

From: Andres Freund <andres(at)anarazel(dot)de>
To: Noah Misch <noah(at)leadboat(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: failing to build preproc.c on solaris with sun studio
Date: 2022-08-06 23:52:16
Message-ID: 20220806235216.b65mtwehhefebnzu@awork3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2022-08-06 16:09:24 -0700, Noah Misch wrote:
> On Sat, Aug 06, 2022 at 02:07:24PM -0700, Andres Freund wrote:
> > I tried PG on the gcc compile farm solaris 11.31 host. When compiling with sun
> > studio I can build the backend etc, but preproc.c fails to compile:
> >
> > ccache /opt/developerstudio12.6/bin/cc -m64 -Xa -g -v -O0 -D_POSIX_PTHREAD_SEMANTICS -mt -D_REENTRANT -D_THREAD_SAFE -I../include -I../../../../src/interfaces/ecpg/include -I. -I. -I../../../../src/interfaces/ecpg/ecpglib -I../../../../src/interfaces/libpq -I../../../../src/include -D_POSIX_PTHREAD_SEMANTICS -c -o preproc.o preproc.c
> > Assertion failed: hmap_size (phdl->fb.map) == 0, file ../src/line_num_internal.c, line 230, function twolist_proc_clear
> > Assertion failed: hmap_size (phdl->fb.map) == 0, file ../src/line_num_internal.c, line 230, function twolist_proc_clear
> > cc: Fatal error in /opt/developerstudio12.6/lib/compilers/bin/acomp
> > cc: Status 134
> >
> > the assertion is just a consequence of running out of memory, I believe, acomp
> > is well over 20GB at that point.
> >
> > However I see that wrasse doesn't seem to have that problem. Which leaves me a
> > bit confused, because I think that's the same machine and compiler binary.
> >
> > Noah, did you encounter this before / do anything to avoid this?
>
> Yes. Drop --enable-debug, and override TMPDIR to some disk-backed location.

Thanks - that indeed helped...

> From the earliest days of wrasse, the compiler used too much RAM to build
> preproc.o with --enable-debug. As of 2021-04, the compiler's "acomp" phase
> needed 10G in one process, and later phases needed 11.6G across two processes.
> Compilation wrote 3.7G into TMPDIR. Since /tmp consumes RAM+swap, overriding
> TMPDIR relieved 3.7G of RAM pressure. Even with those protections, wrasse
> intermittently reaches the 14G limit I impose (via "ulimit -v 14680064"). I
> had experimented with different optimization levels, but that didn't help.

Yikes. And it's not like newer compiler versions are likely to be forthcoming
(12.6 is newest and is from 2017...). Wonder if we should just require gcc on
solaris... There's a decent amount of stuff we could rip out in that case.

I was trying to build on solaris because I was seeing if we could get rid of
with_gnu_ld, motivated by making the meson build generate a working
Makefile.global for pgxs' benefit.

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2022-08-06 23:52:28 Re: Cleaning up historical portability baggage
Previous Message Thomas Munro 2022-08-06 23:47:31 Re: Cleaning up historical portability baggage