On 2022-04-24 Su 14:19, Noah Misch wrote:
> On Sun, Apr 24, 2022 at 01:09:08PM -0400, Andrew Dunstan wrote:
>> On 2022-04-22 Fr 22:59, Noah Misch wrote:
>>> The MinGW gcc crt*.o files do shell-glob expansion on the arguments before
>>> entering main(). See https://google.com/search?q=mingw+command+line+glob for
>>> various discussion of that behavior. I suspect you experienced that, not any
>>> IPC::Run behavior. (I haven't tested, though.) Commit 11e9caf likely had the
>>> same cause, though the commit message attributed it to the msys shell rather
>>> than to crt*.o.
>>>
>>> Let's disable that MinGW compiler behavior.
>>> https://willus.com/mingw/_globbing.shtml lists two ways of achieving that.
>> Yeah. I can definitely confirm that this is the proximate cause of the
>> issue, and not either IPC::Run or the shell, which is why all my
>> experiments on this failed. With this patch
> Thanks for confirming.
>
>> diff --git a/src/include/port/win32.h b/src/include/port/win32.h
>> index c6213c77c3..456c3f31f1 100644
>> --- a/src/include/port/win32.h
>> +++ b/src/include/port/win32.h
>> @@ -77,3 +77,7 @@ struct sockaddr_un
>> char sun_path[108];
>> };
>> #define HAVE_STRUCT_SOCKADDR_UN 1
>> +
>> +#ifndef _MSC_VER
>> +extern int _CRT_glob = 0; /* 0 turns off globbing; 1 turns it on */
>> +#endif
>>
>>
>> fairywren happily passes the tests that Robert has since reverted.
>>
>>
>> I'm rather tempted to call this CRT behaviour a mis-feature, especially
>> as a default. I think we should certainly disable it in the development
>> branch, and consider back-patching it, although it is a slight change in
>> behaviour, albeit one that we didn't know about much less want or
>> document. Still, we been building with mingw compilers for about 20
>> years and haven't hit this before so far as we know, so maybe not.
> I'd lean toward back-patching. We position MSVC and MinGW as two ways to
> build roughly the same PostgreSQL, not as two routes to different user-facing
> behavior. Since the postgresql.org/download binaries use MSVC, aligning with
> their behavior is good. It's fair to mention in the release notes, of course.
OK, good point.
> Does your win32.h patch build without warnings or errors?
Yes.
> Even if MinGW has
> some magic to make that work, I suspect we'll want a non-header home. Perhaps
> src/common/exec.c? It's best to keep this symbol out of libpq and other
> DLLs, though I bet exports.txt would avoid functional problems.
exec.c looks like it should work fine.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
