Hi, On 2024-06-03 17:07:22 +0200, Wolfgang Walther wrote: > Peter Eisentraut: > > It's probably worth clarifying that this option is needed on macOS only > > if LTO is also enabled. For standard (non-LTO) builds, the > > export-dynamic behavior is already the default on macOS (otherwise > > nothing in PostgreSQL would work). > > Right, man page say this: > > > Preserves all global symbols in main executables during LTO. Without this > option, Link Time Optimization is allowed to inline and remove global > functions. This option is used when a main executable may load a plug-in > which requires certain symbols from the main executable.
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. > Peter: > > I don't think we explicitly offer LTO builds as part of the make build > > system, so anyone trying this would do it sort of self-service, by > > passing additional options to configure or make. In which case they > > might as well pass the -export_dynamic option along in the same way? > > The challenge is that it defeats the purpose of LTO to pass this along to > everything, e.g. via CFLAGS. The Makefiles set this in LDFLAGS_EX_BE only, > so it only affects the backend binary. This is not at all obvious and took > me quite a while to figure out why LTO silently didn't strip symbols from > other binaries. It does work to explicitly set LDFLAGS_EX_BE, though. > > 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. 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. Greetings, Andres Freund
