Re: Build with LTO / -flto on macOS

From: Wolfgang Walther <walther(at)technowledgy(dot)de>
To: Andres Freund <andres(at)anarazel(dot)de>, Peter Eisentraut <peter(at)eisentraut(dot)org>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Build with LTO / -flto on macOS
Date: 2024-06-04 16:30:07
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Andres Freund:
> Gah. Apples tendency to just break stuff that has worked across *nix-y
> platforms for decades is pretty annoying. They could just have made
> --export-dynamic an alias for --export_dynamic, but no, everyone needs a
> special macos thingy in their build scripts.

Interesting enough my Linux ld does support -export_dynamic, too.. but
it doesn't say anywhere in the man pages or so.

>> Also, passing the LTO flag on Linux "just works" (clang, not GCC
>> necessarily).
> It should just work on gcc, or at least has in the recent past.

Well it "works" in a sense that the build succeeds and check-world as
well. But there are some symbols in all the client binaries that I know
are unused (paths to .../include etc.), and which LLVM's LTO strips out
happily - that are still in there after GCC's LTO.

GCC can remove them with -fdata-sections -ffunction-sections
-fmerge-constants and -Wl,--gc-sections. But not with -flto. At least I
didn't manage to.

> ISTM if we want to test for -export_dynamic like what you proposed, we should
> do so only if --export-dynamic wasn't found. No need to incur the overhead on
> !macos.

Makes sense! v2 attached.

I also attached a .backpatch to show what that would look like for v15
and down.

Peter Eisentraut:
> 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.

Which macOS versions are "supported"?

I just set up a VM with macOS Mojave (2018) and tested both the .patch
on HEAD as well as the .backpatch on REL_12_STABLE with -flto. Build
passed, make check-world as well.

clang --version for Mojave:
Apple LLVM version 10.0.1 (clang-1001.0.46.4)
Target: x86_64-apple-darwin18.5.0

clang --version for Sonoma (where I tested before):
Apple clang version 15.0.0 (clang-1500.3.9.4)
Target: x86_64-apple-darwin(at)23(dot)5(dot)0

Since PostgreSQL 12 is from 2019 and Mojave from 2018, I think that's
far enough back?

> 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.

Fair enough! Hopefully my testing convinces more than the man pages ;)



Attachment Content-Type Size
v2-0001-Make-building-with-clang-s-LTO-work-on-macOS.patch text/x-patch 4.0 KB
v2-0001-Make-building-with-clang-s-LTO-work-on-macOS.backpatch text/plain 305 bytes

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2024-06-04 16:36:24 Re: meson "experimental"?
Previous Message David G. Johnston 2024-06-04 16:28:18 Re: Patch bug: Fix jsonpath .* on Arrays