Re: Cleaning up historical portability baggage

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Cleaning up historical portability baggage
Date: 2022-08-07 06:20:26
Message-ID: 20220807062026.udo73f5rsnpanvko@awork3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2022-08-07 06:46:32 Re: failing to build preproc.c on solaris with sun studio
Previous Message Tom Lane 2022-08-07 05:17:22 Re: failing to build preproc.c on solaris with sun studio