Обсуждение: master, static inline and #ifndef FRONTEND
Hi, In a recent commit [1] I added a static inline which castoroides dislikes: cc -D_STDC_C99= -Xa -g -m64 -xarch=native -xdepend -xO4 -xprefetch=auto,explicit pg_waldump.o compat.o xlogreader.o rmgrdesc.obrindesc.o clogdesc.o committsdesc.o dbasedesc.o genericdesc.o gindesc.o gistdesc.o hashdesc.o heapdesc.o logicalmsgdesc.omxactdesc.o nbtdesc.o relmapdesc.o replorigindesc.o seqdesc.o smgrdesc.o spgdesc.o standbydesc.o tblspcdesc.oxactdesc.o xlogdesc.o -L../../../src/port -L../../../src/common -Wl,-R'/export/home/dpage/pgbuildfarm/castoroides/HEAD/inst/lib' -lpgcommon -lpgport -lpam -lgss -lz -lnsl -lrt -lsocket-lm -o pg_waldump Undefined first referenced symbol in file slot_getsomeattrs rmgrdesc.o So it's the "old" issue of static inlines referencing functions that aren't present, which newer compilers don't have. It's obviously trivial to fix this case with by adding an #ifndef FRONTEND. But as castoroides appears to be the only animal showing the problem - after subtracting the animals dead due to the C99 requirement - I wonder if we shouldn't just require "proper" static inline support. castoroides runs a 13yo OS, and newer compilers that do not have the problem are readily available. I think it's very likely that we'll add more and more static inlines, and having to either experimentally check via the buildfarm, or just add #ifndef FRONTEND everywhere is pretty annoying. Greetings, Andres Freund [1] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=88ebd62fcc2ea7c55c0858f6dd4800d51383529f [2] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=castoroides&dt=2018-08-24%2012%3A03%3A05
Andres Freund <andres@anarazel.de> writes:
> In a recent commit [1] I added a static inline which castoroides
> dislikes: ...
> It's obviously trivial to fix this case with by adding an #ifndef
> FRONTEND. But as castoroides appears to be the only animal showing the
> problem - after subtracting the animals dead due to the C99 requirement
> - I wonder if we shouldn't just require "proper" static inline
> support. castoroides runs a 13yo OS, and newer compilers that do not
> have the problem are readily available.
Given that we currently have *no* working Solaris buildfarm members,
I'm not prepared to tolerate "I can't be bothered to fix this",
which is what your argument boils down to. We need to get at least
one of castoroides and protosciurus back to green so that we can
do platform-specific testing there [1], and castoroides appears to be
the easier one to fix in the short term.
In the long run it may well be reasonable to shift focus to newer
compilers and/or newer Solaris versions, but for today, I'm going
to go add the #ifndef.
regards, tom lane
[1] for instance,
https://www.postgresql.org/message-id/16984.1536596764%40sss.pgh.pa.us
Hi, On 2018-09-10 12:39:16 -0400, Tom Lane wrote: > Andres Freund <andres@anarazel.de> writes: > > In a recent commit [1] I added a static inline which castoroides > > dislikes: ... > > It's obviously trivial to fix this case with by adding an #ifndef > > FRONTEND. But as castoroides appears to be the only animal showing the > > problem - after subtracting the animals dead due to the C99 requirement > > - I wonder if we shouldn't just require "proper" static inline > > support. castoroides runs a 13yo OS, and newer compilers that do not > > have the problem are readily available. > > Given that we currently have *no* working Solaris buildfarm members, > I'm not prepared to tolerate "I can't be bothered to fix this", > which is what your argument boils down to. Uh, this seems unnecessarily dismissive. I wrote the above email minutes after noticing the issue ( which in turn was shortly after the issue occured), asking for feedback. Hardly "I can't be bothered to fix it" territory. But adding a lot of #ifndef FRONTENDs isn't entirely free either... > We need to get at least one of castoroides and protosciurus back to > green so that we can do platform-specific testing there [1], and > castoroides appears to be the easier one to fix in the short term. Note that rover-firefly runs on a solaris-ish environment and indeed shows a problem https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=rover_firefly&dt=2018-09-10%2015%3A11%3A16 - Andres
Hi, On 2018-09-10 09:50:15 -0700, Andres Freund wrote: > On 2018-09-10 12:39:16 -0400, Tom Lane wrote: > > Andres Freund <andres@anarazel.de> writes: > > > In a recent commit [1] I added a static inline which castoroides > > > dislikes: ... > > > It's obviously trivial to fix this case with by adding an #ifndef > > > FRONTEND. But as castoroides appears to be the only animal showing the > > > problem - after subtracting the animals dead due to the C99 requirement > > > - I wonder if we shouldn't just require "proper" static inline > > > support. castoroides runs a 13yo OS, and newer compilers that do not > > > have the problem are readily available. > > > > Given that we currently have *no* working Solaris buildfarm members, > > I'm not prepared to tolerate "I can't be bothered to fix this", > > which is what your argument boils down to. > > Uh, this seems unnecessarily dismissive. I wrote the above email minutes > after noticing the issue ( which in turn was shortly after the issue > occured), asking for feedback. Hardly "I can't be bothered to fix it" > territory. But adding a lot of #ifndef FRONTENDs isn't entirely free > either... Fwi, I've pinged Dave about upgrading the compiler on that machine, and he wrote: On 2018-09-26 17:04:29 -0400, Dave Page wrote: > Unfortunately, i think that whole machine is basically EOL now. It's > already skipping OpenSSL for some builds, as being stuck on a very old > version of the buildfarm client, as some of the modules used in newer > versions just won't compile or work. I don't have any support contract, or > access to newer versions of SunStudio, and the guys that used to package > GCC for Solaris now charge to download their packages. he has subsequently disabled building master on protosciurus and casteroides. Greetings, Andres Freund