Re: Build with LTO / -flto on macOS

From: Peter Eisentraut <peter(at)eisentraut(dot)org>
To: Aleksander Alekseev <aleksander(at)timescale(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Cc: Wolfgang Walther <walther(at)technowledgy(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)anarazel(dot)de>
Subject: Re: Build with LTO / -flto on macOS
Date: 2024-07-22 14:04:11
Message-ID: 1f9ab49c-4a6a-49b0-9221-a30940806cb9@eisentraut.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 19.07.24 12:40, Aleksander Alekseev wrote:
> It seems to me that the patch is not going to become any better and it
> doesn't need any more attention from the reviewers. Thus I changed the
> status of the CF entry to "Ready for Committer".

I'm happy to commit this patch.

I checked that for non-LTO builds, this option does not change the
output binary, so it seems harmless in that sense.

An equivalent change has recently been merged into meson upstream, so
we'll get the same behavior on meson before long.

The argument "If you're going to manually inject -flto, seems like you
could manually inject -Wl,-export_dynamic too, so why do you need this
patch?" is true, but the behavior that the link fails unless you use
both options is pretty surprising, so this is a small quality of life
improvement. Also, it seems that LTO use is already in the wild, so it
seems sensible to make that easier to exercise during development too.
Maybe a configure --enable-lto option would be sensible, but that can be
a separate patch.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2024-07-22 14:11:55 Re: Vacuum ERRORs out considering freezing dead tuples from before OldestXmin
Previous Message Ertan Küçükoglu 2024-07-22 13:51:27 Re: Windows default locale vs initdb