Обсуждение: pgsql: Avoid unsatisfied-external-reference errors in static inlines.
Avoid unsatisfied-external-reference errors in static inlines. Commit 9c727360b neglected the lesson we've learned before: protect references to backend global variables with #ifndef FRONTEND. Since there's already a place for static inlines in this file, move the just-converted functions to that stanza. Undo the entirely gratuitous de-macroization of RelationGetNumberOfBlocks (that one may be okay, since it has no global variable references, but it's also pointless). Per buildfarm. Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/27d2693187d1bcf2563ee7142ba37d4788c8d52b Modified Files -------------- src/include/storage/bufmgr.h | 166 +++++++++++++++++++++---------------------- 1 file changed, 80 insertions(+), 86 deletions(-)
On 13.07.22 19:37, Tom Lane wrote: > Avoid unsatisfied-external-reference errors in static inlines. > > Commit 9c727360b neglected the lesson we've learned before: > protect references to backend global variables with #ifndef FRONTEND. What platforms did this fail on? How can one observe the failure locally?
Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes: > What platforms did this fail on? How can one observe the failure locally? wrasse at least: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=wrasse&dt=2022-07-13%2014%3A49%3A17 I think possibly you could duplicate the problem with gcc by using -fkeep-inline-functions, but I've not tried. regards, tom lane
On 13.07.22 20:24, Tom Lane wrote: > Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes: >> What platforms did this fail on? How can one observe the failure locally? > > wrasse at least: > > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=wrasse&dt=2022-07-13%2014%3A49%3A17 > > I think possibly you could duplicate the problem with gcc > by using -fkeep-inline-functions, but I've not tried. Confirmed, -fkeep-inline-functions will catch it. Good to know.
On 14.07.22 12:05, Peter Eisentraut wrote: > On 13.07.22 20:24, Tom Lane wrote: >> Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes: >>> What platforms did this fail on? How can one observe the failure >>> locally? >> >> wrasse at least: >> >> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=wrasse&dt=2022-07-13%2014%3A49%3A17 >> >> >> I think possibly you could duplicate the problem with gcc >> by using -fkeep-inline-functions, but I've not tried. > > Confirmed, -fkeep-inline-functions will catch it. Good to know. It seems that -fkeep-inline-functions is more demanding than what wrasse is running on. I need the attached patch to get it to build cleanly. (The first hunk undoes some parts of 2cd2569c72b8920048e35c31c9be30a6170e1410, but the others are unrelated and old.) I think this would be good to apply so that this method of checking inline functions is available in the future.
Вложения
Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
> It seems that -fkeep-inline-functions is more demanding than what wrasse
> is running on. I need the attached patch to get it to build cleanly.
Interesting. I'm not entirely clear on which external references
cause wrasse to spit up.
> I think this would be good to apply so that this method of checking
> inline functions is available in the future.
+1
regards, tom lane