Horton

Re: Build with LTO / -flto on macOS

Wolfgang Walther <walther@technowledgy.de>

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

Attachments

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