We introduced LTO in #294504. At that time, we still needed to use LLVM
/ lld to make this work on darwin. For this to work for extensions, they
would need to set CFLAGS=-fuse-ld=lld, too. However, since #307880
landed, we don't need to do this anymore in the first place, LTO just
works out of the box on darwin.
Resolves#342362
This was supposed to happen in #294504, but the commit was accidentally
left out when splitting off some libpq-related changes. Originated in
#179962, by Sandro.
Co-authored-by: Sandro Jäckel <sandro.jaeckel@gmail.com>
Co-authored-by: Wolfgang Walther <walther@technowledgy.de>
The !isDarwin condition seems to have been put in place only because of the
use of patchelf, which in turn seemed to be necessary because of nuke-refs.
Replacing the big nuke with the more granular remove-references-to allows
enabling this for darwin, too.
This splits a dev output to make the default output not depend on any
build dependencies anymore. This also avoids removing references from
pgxs' Makefile this way, which should, at least theoretically, be good
to build extensions via pgxs, making sure they use the same tooling.
ecpg is the "embedded SQL C preprocessor", which is certainly a dev
tool.
Most important, for closure size anyway, is to move pg_config to the dev
output, since it retains paths to all the other outputs.
The only thing with references to the dev output remaining is then the
postgres binary itself. It contains all the output paths, because it
shows those in the pg_config system view. There is no other way than
to nuke those references to avoid circular dependencies between outputs
- and blowing up closure size again.
This library is used by other packages, so should be in the lib output.
By removing unused sections, libecpg will not contain any references to other
outputs and thus does not increase the closure for the lib output anymore.
This will also help massively when splitting a dev output later.
As a side-effect, this also unbreaks pkgsMusl.postgresql_12_jit and
pkgsMusl.postgresql_13_jit. For, at least to me, unknown reasons, those build
fine now.
Dynamic modules are technically libraries, but are not used by other packages.
Instead they are loaded by PostgreSQL itself, e.g. as extensions. Those just
increased the size of the lib output without benefit.
This removes the NIX_PGLIBDIR hack introduced in #17838 and instead makes sure
that pg_config always returns the correct PGLIBDIR. The test for postgis
introduced in the same PR is still passing with the change.
