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.
* postgresqlPackages.timescaledb_toolkit: fix on macos
It looks like the macOS linker doesn’t like that some of the symbols
are undefined in the extension. They will be provided by the postgres
binary, but macOS linker checks that all symbols are defined.
Apparently, Linux allows these symbols to be undefined.
The -undefined flag changes this behavior:
> Specifies how undefined symbols are to be treated. Options are:
> error, warning, suppress, or dynamic_lookup. The default is error.
So, setting to dynamic_lookup makes the most sense here, and makes
this package work on macOS. I tried to see if pgvecto-rs, which also
uses buildPgrxExtension, would build. Unfortunately, it gave other
errors.
More information on the bug here: https://github.com/supabase/nix-postgres/issues/10
* Remove stdenv
