Re: Cleaning up historical portability baggage - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Cleaning up historical portability baggage
Date
Msg-id 20220807062026.udo73f5rsnpanvko@awork3.anarazel.de
Whole thread Raw
In response to Re: Cleaning up historical portability baggage  (Andres Freund <andres@anarazel.de>)
Responses Re: Cleaning up historical portability baggage
List pgsql-hackers
Hi,

On 2022-08-06 20:39:48 -0700, Andres Freund wrote:
> On 2022-08-06 22:58:12 -0400, Tom Lane wrote:
> > You could pull it out and see if the buildfarm breaks, but my money
> > is on it breaking.  That HAVE_BUGGY_STRTOF stuff isn't very old.
> 
> We only recently figured out that we should use the ucrt runtime (and that it
> exists, I guess).
> fairywren and jacan's first runs with ucrt are from mid February:
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=fairywren&dt=2022-02-13%2007%3A11%3A46
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jacana&dt=2022-02-17%2016%3A15%3A24

Well, bad news and good news. The bad: We get the wrong results when just
removing HAVE_BUGGY_STRTOF. The good: That is just because we haven't applied
enough, or the right, magic. To have mingw to not interfere with things one
also has to pass -D_UCRT and -lucrt - then the tests pass, even without
HAVE_BUGGY_STRTOF.

I think this might also explain (and fix) some other oddity we had with mingw
that I was getting confused about a while back, but I forgot too much of the
details...

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: failing to build preproc.c on solaris with sun studio
Next
From: Andres Freund
Date:
Subject: Re: failing to build preproc.c on solaris with sun studio