_CRT_glob stuff
When you compile on Windows with a sufficiently new gcc or clang you'll
get errors or warnings like this:
../src/common/exec.c:49:17: error: '_CRT_glob' initialized and declared
'extern' [-Werror]
49 | extern int _CRT_glob = 0; /* 0 turns off
globbing; 1 turns it on */
or
../src/common/exec.c:49:12: error: 'extern' variable has an initializer
[-Werror,-Wextern-initializer]
49 | extern int _CRT_glob = 0; /* 0 turns off
globbing; 1 turns it on */
| ^
../src/common/exec.c:49:12: error: no previous extern declaration for
non-static variable '_CRT_glob' [-Werror,-Wmissing-variable-declarations]
../src/common/exec.c:49:8: note: declare 'static' if the variable is not
intended to be used outside of this translation unit
49 | extern int _CRT_glob = 0; /* 0 turns off
globbing; 1 turns it on */
| ^
(You can test this out on non-Windows by disabling the #if around it in
src/common/exec.c.)
It took me a bit of research to figure out what
extern int foo = 0;
even means. It turns out that the "extern" is ignored in that case. So
I suggest we remove it from the code, to eliminate the confusion and the
warnings. And then we have to add in a real extern declaration (without
initializer) to satisfy -Wmissing-variable-declarations. So it should
look like
diff --git a/src/common/exec.c b/src/common/exec.c
index 8b690a10185..cca89f04074 100644
--- a/src/common/exec.c
+++ b/src/common/exec.c
@@ -46,7 +46,8 @@ /* Inhibit mingw CRT's auto-globbing of command line arguments */
#if defined(WIN32) && !defined(_MSC_VER)
-extern int _CRT_glob = 0; /* 0 turns off globbing; 1 turns it on */
+extern int _CRT_glob;
+int _CRT_glob = 0; /* 0 turns off globbing; 1 turns it
on */
#endif/*
Here is some relevant documentation that suggests that this is the
correct approach:
https://github.com/mingw-w64/mingw-w64/blob/master/mingw-w64-headers/crt/_mingw.h.in#L476
This also says that the default is 0 anyway, so it's not clear whether
this is even useful anymore. The commit that introduced this (commit
b787c554c26) is from 2022, so it's not that long ago. (It appears to be
some old mingw vs. new mingw issue?)
On Thu, Sep 18, 2025 at 3:03 AM Peter Eisentraut <peter@eisentraut.org> wrote:
Here is some relevant documentation that suggests that this is the
correct approach:https://github.com/mingw-w64/mingw-w64/blob/master/mingw-w64-headers/crt/_mingw.h.in#L476
This also says that the default is 0 anyway, so it's not clear whether
this is even useful anymore. The commit that introduced this (commit
b787c554c26) is from 2022, so it's not that long ago. (It appears to be
some old mingw vs. new mingw issue?)
So if MinGW already defines its own version of this symbol [1]https://github.com/mingw-w64/mingw-w64/blob/8181947c/mingw-w64-crt/crt/wildcard.c, how
does this work in practice? Would it actually do anything if we
assigned -1 instead?
--Jacob
[1]: https://github.com/mingw-w64/mingw-w64/blob/8181947c/mingw-w64-crt/crt/wildcard.c
On 18.09.25 17:15, Jacob Champion wrote:
On Thu, Sep 18, 2025 at 3:03 AM Peter Eisentraut <peter@eisentraut.org> wrote:
Here is some relevant documentation that suggests that this is the
correct approach:https://github.com/mingw-w64/mingw-w64/blob/master/mingw-w64-headers/crt/_mingw.h.in#L476
This also says that the default is 0 anyway, so it's not clear whether
this is even useful anymore. The commit that introduced this (commit
b787c554c26) is from 2022, so it's not that long ago. (It appears to be
some old mingw vs. new mingw issue?)So if MinGW already defines its own version of this symbol [1], how
does this work in practice? Would it actually do anything if we
assigned -1 instead?
Yes, if you do that, the pg_amcheck test 'schema exclusion pattern
overrides all inclusion patterns' fails, which has an entirely plausible
causality.
As to how it works, I'm not sure, but I suppose the linker somehow
arranges the initializations in the right order.
On Fri, Sep 19, 2025 at 12:37 AM Peter Eisentraut <peter@eisentraut.org> wrote:
As to how it works, I'm not sure, but I suppose the linker somehow
arranges the initializations in the right order.
Okay. I was a bit concerned that, if libpq pulled in this symbol via
pgcommon, it might accidentally affect the client executable... but I
guess our exports files are saving us there, and in any case the
executable's symbol (if defined) should win anyway. Carry on :)
--Jacob
On 18.09.25 12:02, Peter Eisentraut wrote:
So it should look like
diff --git a/src/common/exec.c b/src/common/exec.c index 8b690a10185..cca89f04074 100644 --- a/src/common/exec.c +++ b/src/common/exec.c @@ -46,7 +46,8 @@/* Inhibit mingw CRT's auto-globbing of command line arguments */ #if defined(WIN32) && !defined(_MSC_VER) -extern int _CRT_glob = 0; /* 0 turns off globbing; 1 turns it on */ +extern int _CRT_glob; +int _CRT_glob = 0; /* 0 turns off globbing; 1 turns it on */ #endif/*
I have committed this.