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

From Andres Freund
Subject Re: Cleaning up historical portability baggage
Date
Msg-id 20220807033948.p5kqmdy2hteq33ou@awork3.anarazel.de
Whole thread Raw
In response to Re: Cleaning up historical portability baggage  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Cleaning up historical portability baggage
List pgsql-hackers
Hi,

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

We probably should just throw an error if msvcrt is used. That's the old, pre
C99, microsoft C runtime, with some mingw replacement functions ontop.  I
think our tests already don't pass when it's used. See [1] for more info.

Not entirely sure how to best detect ucrt use - we could just check MSYSTEM,
but that's not determinative because one also can specify the compiler via the
prefix...


That'd still leave us with the alternative output files due to cygwin, I
think.

Greetings,

Andres Freund


[1] https://www.msys2.org/docs/environments/



pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: failing to build preproc.c on solaris with sun studio
Next
From: Dilip Kumar
Date:
Subject: Re: [Proposal] Fully WAL logged CREATE DATABASE - No Checkpoints