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
Re: Raising our compiler requirements for 9.6 |
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: