Re: Raising our compiler requirements for 9.6

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.  (But is pademelon really the only buildfarm critter relying
on the "fallback" atomics implementation?)

Another possible angle is: what the heck does pg_resetxlog need with
atomic ops, anyway?  Should these things have a different, stub
implementation for FRONTEND code?
        regards, tom lane