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.
Attachments:
0001-WIP-Support-gcc-fkeep-inline-functions.patchtext/plain; charset=UTF-8; name=0001-WIP-Support-gcc-fkeep-inline-functions.patchDownload+13-16
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