Re: Raising our compiler requirements for 9.6 - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Raising our compiler requirements for 9.6
Date
Msg-id 20150806070902.GE12214@awork2.anarazel.de
Whole thread Raw
In response to Re: Raising our compiler requirements for 9.6  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Raising our compiler requirements for 9.6  (Andres Freund <andres@anarazel.de>)
Re: Raising our compiler requirements for 9.6  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On 2015-08-05 23:18:08 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > ... I'm going to reshuffle things in that direction tomorrow. I'll
> > wait for other fallout first though. So far only gcc, xlc and clang (via
> > gcc frontend) have run...
> 
> In the department of "other fallout", pademelon is not happy:
> 
> cc -Ae -g +O0 -Wp,-H16384 -I../../../src/include -D_XOPEN_SOURCE_EXTENDED
-I/usr/local/libxml2-2.6.23/include/libxml2-I/usr/local/include  -c -o pg_resetxlog.o pg_resetxlog.c
 
> cc -Ae -g +O0 -Wp,-H16384 pg_resetxlog.o -L../../../src/port -L../../../src/common -L/usr/local/libxml2-2.6.23/lib
-L/usr/local/lib-Wl,+b -Wl,'/home/bfarm/bf-data/HEAD/inst/lib'  -Wl,-z -lpgcommon -lpgport -lxnet -lxml2 -lz -lreadline
-ltermcap-lm  -o pg_resetxlog
 
> /usr/ccs/bin/ld: Unsatisfied symbols:
>    pg_atomic_clear_flag_impl (code)
>    pg_atomic_init_flag_impl (code)
>    pg_atomic_compare_exchange_u32_impl (code)
>    pg_atomic_fetch_add_u32_impl (code)
>    pg_atomic_test_set_flag_impl (code)
>    pg_atomic_init_u32_impl (code)
> make[3]: *** [pg_resetxlog] Error 1
> 
> I'd have thought that port/atomics.c would be included in libpgport, but
> it seems not.

Given that it requires spinlocks for the fallback, which in turn may
require semaphores, that didn't seem like a good idea. Thus atomics.c is
in src/backend/port not src/port (just like other locking stuff like
spinlocks, semaphores etc).

> (But is pademelon really the only buildfarm critter relying
> on the "fallback" atomics implementation?)

I don't think so. At least that didn't use to be the case. My guess is
that less ancient compilers don't emit code for unreferenced functions
and this thus doesn't show up.

> Another possible angle is: what the heck does pg_resetxlog need with
> atomic ops, anyway?

It really doesn't. It's just fallout from indirectly including lwlock.h
which includes an atomic variable. The include path leading to it is

In file included from /home/andres/src/postgresql/src/include/storage/lwlock.h:19:0,                from
/home/andres/src/postgresql/src/include/storage/lock.h:18,               from
/home/andres/src/postgresql/src/include/access/tuptoaster.h:18,               from
/home/andres/src/postgresql/src/bin/pg_resetxlog/pg_resetxlog.c:49:
/home/andres/src/postgresql/src/include/port/atomics.h:41:2: error: #error "THOU SHALL NOT REQUIRE ATOMICS"#error "THOU
SHALLNOT REQUIRE ATOMICS"
 

There's other path's (slot.h) as well if that were fixed.

> Should these things have a different, stub implementation for FRONTEND
> code?

I'm honestly not yet sure what the best approach here would be.

One approach is to avoid including lwlock.h/slot.h in frontend
code. That'll require some minor surgery and adding a couple includes,
but it doesn't look that bad.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Mikko Tiihonen
Date:
Subject: Re: [PATCH] libpq: Allow specifying multiple host names to try to connect to
Next
From: Pavel Stehule
Date:
Subject: Re: raw output from copy