Re: Build with LTO / -flto on macOS

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 ;)

Best,

Wolfgang