Aleksander Alekseev <aleksander@timescale.com> writes:
> 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".
So ... there is quite a disconnect between what this patch actually
does (i.e., probe to see if "-Wl,-export_dynamic" is accepted) and
the title of this thread. I wouldn't have much of a problem with
the patch in isolation. However, what Apple's man page for ld(1)
says is
-export_dynamic
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.
which agrees with Wolfgang's comment that it doesn't do much unless
you enable LTO. So that raises two questions:
1. 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?
2. Do we really want to encourage people to build with -flto?
I fear that #2 is actually a pretty serious concern. I think there
are a lot of places where we've assumed semi-implicitly that
compilation file boundaries are optimization barriers, particularly
around stuff like LWLocks and semaphores. I don't really want to
spend time chasing obscure, irreproducible bugs that may appear when
that assumption gets broken. I especially don't want to do it just
because some packager has randomly decided to inject random build
switches.
In short: if we want to support LTO, let's do it officially and not
by the back door. But I think somebody needs to make the case that
there are compelling benefits that would justify the nontrivial
amount of risk and work that may ensue. My default position here
is "sorry, we don't support that".
regards, tom lane