Horton

Re: Build with LTO / -flto on macOS

Peter Eisentraut <peter@eisentraut.org>

View thread
From: Peter Eisentraut <peter@eisentraut.org>
To: Wolfgang Walther <walther@technowledgy.de>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Andres Freund <andres@anarazel.de>
Date: 2024-06-04T07:26:06Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Make building with LTO work on macOS

  2. Require memory barrier support.

  3. Require compiler barrier support.

  4. autoconf: Move export_dynamic determination to configure

On 03.06.24 17:07, Wolfgang Walther wrote:
>> I don't mind addressing this in PG18, but I would hesitate with 
>> backpatching.  With macOS, it's always hard to figure out whether 
>> these kinds of options work the same way going versions back.
> 
> All the versions for ld64 are in [1]. It seems this was introduced in 
> ld64-224.1 [2] the first time. It was not there in ld64-136 [3]. Finally 
> the man page has **exactly** the same wording in the latest version 
> ld64-609 [4].
> 
> We could go further and compare the source, but I think it's safe to 
> assume that this flag hasn't changed much and should not affect non-LTO 
> builds. And for even older versions it would just not be supported, so 
> configure would not use it.

With the native compiler tooling on macOS, it is not safe to assume 
anything, including that the man pages are accurate or that the 
documented options actually work correctly and don't break anything 
else.  Unless we have actual testing on all the supported macOS 
versions, I don't believe it.

Given that LTO apparently never worked on macOS, this is not a 
regression, so I wouldn't backpatch it.  I'm not objecting, but I don't 
want to touch it.