2024-11-23 23:36:23 +01:00
|
|
|
{
|
|
|
|
# utils
|
|
|
|
stdenv,
|
2025-02-18 10:20:13 +01:00
|
|
|
fetchFromGitHub,
|
2024-11-23 23:36:23 +01:00
|
|
|
lib,
|
|
|
|
|
|
|
|
# runtime dependencies
|
|
|
|
openssl,
|
|
|
|
tzdata,
|
|
|
|
zlib,
|
|
|
|
|
|
|
|
# build dependencies
|
|
|
|
bison,
|
|
|
|
flex,
|
2025-02-15 18:50:30 +01:00
|
|
|
makeWrapper,
|
2024-11-23 23:36:23 +01:00
|
|
|
perl,
|
|
|
|
pkg-config,
|
|
|
|
|
|
|
|
# passthru / meta
|
|
|
|
postgresql,
|
postgresql: replace pg_config with custom script
By replacing upstream's pg_config binary with a shell script, we:
- gain the ability to run pg_config easily when cross-compiling,
- can remove the fake pg_config in the default output,
- can remove the pg_config wrapper script dealing with special cases.
Some 20 years ago, pg_config *was* a shell script upstream, too. It was
changed to a binary, when it was made "relocatable", so it would return
paths depending on the location of the "postgres" binary. However, this
is exactly the thing that just hurts us in nixpkgs - we don't want those
paths to change, we want them to always point at the right outputs. By
writing the script ourselves, this becomes a lot less painful.
This approach means more lines of codes, but all of them are dead simple
and we have a lot less complexity overall.
Additionally, pg_config is now made a separate derivation, only exposed
as "postgresql.pg_config". This has the nice side-effect, that all users
of postgresql and libpq in nixpkgs must be very *explicit* about their
dependency on pg_config. This gives a lot more visibility into the state
of affairs regarding pkg-config support for libpq, which ultimately is
the much better solution.
2025-03-10 19:35:50 +01:00
|
|
|
buildPackages,
|
2024-11-23 23:36:23 +01:00
|
|
|
|
|
|
|
# GSSAPI
|
|
|
|
gssSupport ? with stdenv.hostPlatform; !isWindows && !isStatic,
|
|
|
|
libkrb5,
|
|
|
|
|
|
|
|
# NLS
|
|
|
|
nlsSupport ? false,
|
|
|
|
gettext,
|
|
|
|
}:
|
|
|
|
|
|
|
|
stdenv.mkDerivation (finalAttrs: {
|
|
|
|
pname = "libpq";
|
2025-05-07 20:30:55 +02:00
|
|
|
version = "17.5";
|
2024-11-23 23:36:23 +01:00
|
|
|
|
2025-02-18 10:20:13 +01:00
|
|
|
src = fetchFromGitHub {
|
|
|
|
owner = "postgres";
|
|
|
|
repo = "postgres";
|
|
|
|
# rev, not tag, on purpose: see generic.nix.
|
2025-05-07 20:30:55 +02:00
|
|
|
rev = "refs/tags/REL_17_5";
|
|
|
|
hash = "sha256-jWV7hglu7IPMZbqHrZVZHLbZYjVuDeut7nH50aSQIBc=";
|
2024-11-23 23:36:23 +01:00
|
|
|
};
|
|
|
|
|
|
|
|
__structuredAttrs = true;
|
|
|
|
|
|
|
|
hardeningEnable = lib.optionals (!stdenv.cc.isClang) [ "pie" ];
|
|
|
|
|
|
|
|
outputs = [
|
|
|
|
"out"
|
|
|
|
"dev"
|
|
|
|
];
|
|
|
|
outputChecks.out = {
|
|
|
|
disallowedReferences = [ "dev" ];
|
|
|
|
disallowedRequisites = [
|
|
|
|
stdenv.cc
|
|
|
|
]
|
|
|
|
++ (map lib.getDev (builtins.filter (drv: drv ? "dev") finalAttrs.buildInputs));
|
|
|
|
};
|
|
|
|
|
|
|
|
buildInputs = [
|
|
|
|
zlib
|
|
|
|
openssl
|
|
|
|
]
|
|
|
|
++ lib.optionals gssSupport [ libkrb5 ]
|
|
|
|
++ lib.optionals nlsSupport [ gettext ];
|
|
|
|
|
|
|
|
nativeBuildInputs = [
|
|
|
|
bison
|
|
|
|
flex
|
2025-02-15 18:50:30 +01:00
|
|
|
makeWrapper
|
2024-11-23 23:36:23 +01:00
|
|
|
perl
|
|
|
|
pkg-config
|
|
|
|
];
|
|
|
|
|
|
|
|
# causes random build failures
|
|
|
|
enableParallelBuilding = false;
|
|
|
|
|
|
|
|
separateDebugInfo = true;
|
|
|
|
|
|
|
|
buildFlags = [
|
|
|
|
"submake-libpgport"
|
|
|
|
"submake-libpq"
|
|
|
|
];
|
|
|
|
|
|
|
|
# libpgcommon.a and libpgport.a contain all paths normally returned by pg_config and are
|
|
|
|
# linked into all shared libraries. However, almost no binaries actually use those paths.
|
|
|
|
# The following flags will remove unused sections from all shared libraries - including
|
|
|
|
# those paths. This avoids a lot of circular dependency problems with different outputs,
|
|
|
|
# and allows splitting them cleanly.
|
|
|
|
env.CFLAGS =
|
|
|
|
"-fdata-sections -ffunction-sections"
|
|
|
|
+ (if stdenv.cc.isClang then " -flto" else " -fmerge-constants -Wl,--gc-sections");
|
|
|
|
|
2025-04-05 13:37:08 +02:00
|
|
|
# This flag was introduced upstream in:
|
|
|
|
# https://github.com/postgres/postgres/commit/b6c7cfac88c47a9194d76f3d074129da3c46545a
|
|
|
|
# It causes errors when linking against libpq.a in pkgsStatic:
|
|
|
|
# undefined reference to `pg_encoding_to_char'
|
|
|
|
# Unsetting the flag fixes it. The upstream reasoning to introduce it is about the risk
|
|
|
|
# to have initdb load a libpq.so from a different major version and how to avoid that.
|
|
|
|
# This doesn't apply to us with Nix.
|
|
|
|
env.NIX_CFLAGS_COMPILE = "-UUSE_PRIVATE_ENCODING_FUNCS";
|
|
|
|
|
2024-11-23 23:36:23 +01:00
|
|
|
configureFlags = [
|
|
|
|
"--enable-debug"
|
|
|
|
"--sysconfdir=/etc"
|
|
|
|
"--with-openssl"
|
|
|
|
"--with-system-tzdata=${tzdata}/share/zoneinfo"
|
|
|
|
"--without-icu"
|
|
|
|
"--without-perl"
|
|
|
|
"--without-readline"
|
|
|
|
]
|
|
|
|
++ lib.optionals gssSupport [ "--with-gssapi" ]
|
|
|
|
++ lib.optionals nlsSupport [ "--enable-nls" ];
|
|
|
|
|
|
|
|
patches = lib.optionals stdenv.hostPlatform.isLinux [
|
|
|
|
./patches/socketdir-in-run-13+.patch
|
|
|
|
];
|
|
|
|
|
postgresql: replace pg_config with custom script
By replacing upstream's pg_config binary with a shell script, we:
- gain the ability to run pg_config easily when cross-compiling,
- can remove the fake pg_config in the default output,
- can remove the pg_config wrapper script dealing with special cases.
Some 20 years ago, pg_config *was* a shell script upstream, too. It was
changed to a binary, when it was made "relocatable", so it would return
paths depending on the location of the "postgres" binary. However, this
is exactly the thing that just hurts us in nixpkgs - we don't want those
paths to change, we want them to always point at the right outputs. By
writing the script ourselves, this becomes a lot less painful.
This approach means more lines of codes, but all of them are dead simple
and we have a lot less complexity overall.
Additionally, pg_config is now made a separate derivation, only exposed
as "postgresql.pg_config". This has the nice side-effect, that all users
of postgresql and libpq in nixpkgs must be very *explicit* about their
dependency on pg_config. This gives a lot more visibility into the state
of affairs regarding pkg-config support for libpq, which ultimately is
the much better solution.
2025-03-10 19:35:50 +01:00
|
|
|
postPatch = ''
|
|
|
|
cat ${./pg_config.env.mk} >> src/common/Makefile
|
|
|
|
'';
|
|
|
|
|
2024-11-23 23:36:23 +01:00
|
|
|
installPhase = ''
|
|
|
|
runHook preInstall
|
|
|
|
|
postgresql: replace pg_config with custom script
By replacing upstream's pg_config binary with a shell script, we:
- gain the ability to run pg_config easily when cross-compiling,
- can remove the fake pg_config in the default output,
- can remove the pg_config wrapper script dealing with special cases.
Some 20 years ago, pg_config *was* a shell script upstream, too. It was
changed to a binary, when it was made "relocatable", so it would return
paths depending on the location of the "postgres" binary. However, this
is exactly the thing that just hurts us in nixpkgs - we don't want those
paths to change, we want them to always point at the right outputs. By
writing the script ourselves, this becomes a lot less painful.
This approach means more lines of codes, but all of them are dead simple
and we have a lot less complexity overall.
Additionally, pg_config is now made a separate derivation, only exposed
as "postgresql.pg_config". This has the nice side-effect, that all users
of postgresql and libpq in nixpkgs must be very *explicit* about their
dependency on pg_config. This gives a lot more visibility into the state
of affairs regarding pkg-config support for libpq, which ultimately is
the much better solution.
2025-03-10 19:35:50 +01:00
|
|
|
make -C src/common install pg_config.env
|
2024-11-23 23:36:23 +01:00
|
|
|
make -C src/include install
|
|
|
|
make -C src/interfaces/libpq install
|
|
|
|
make -C src/port install
|
|
|
|
|
postgresql: replace pg_config with custom script
By replacing upstream's pg_config binary with a shell script, we:
- gain the ability to run pg_config easily when cross-compiling,
- can remove the fake pg_config in the default output,
- can remove the pg_config wrapper script dealing with special cases.
Some 20 years ago, pg_config *was* a shell script upstream, too. It was
changed to a binary, when it was made "relocatable", so it would return
paths depending on the location of the "postgres" binary. However, this
is exactly the thing that just hurts us in nixpkgs - we don't want those
paths to change, we want them to always point at the right outputs. By
writing the script ourselves, this becomes a lot less painful.
This approach means more lines of codes, but all of them are dead simple
and we have a lot less complexity overall.
Additionally, pg_config is now made a separate derivation, only exposed
as "postgresql.pg_config". This has the nice side-effect, that all users
of postgresql and libpq in nixpkgs must be very *explicit* about their
dependency on pg_config. This gives a lot more visibility into the state
of affairs regarding pkg-config support for libpq, which ultimately is
the much better solution.
2025-03-10 19:35:50 +01:00
|
|
|
install -D src/common/pg_config.env "$dev/nix-support/pg_config.env"
|
2024-11-23 23:36:23 +01:00
|
|
|
moveToOutput "lib/*.a" "$dev"
|
|
|
|
|
|
|
|
rm -rfv $out/share
|
|
|
|
rm -rfv $dev/lib/*_shlib.a
|
|
|
|
|
|
|
|
runHook postInstall
|
|
|
|
'';
|
|
|
|
|
|
|
|
# PostgreSQL always builds both shared and static libs, so we delete those we don't want.
|
|
|
|
postInstall =
|
|
|
|
if stdenv.hostPlatform.isStatic then
|
|
|
|
''
|
|
|
|
rm -rfv $out/lib/*.so*
|
|
|
|
touch $out/empty
|
|
|
|
''
|
|
|
|
else
|
|
|
|
"rm -rfv $dev/lib/*.a";
|
|
|
|
|
|
|
|
doCheck = false;
|
|
|
|
|
postgresql: replace pg_config with custom script
By replacing upstream's pg_config binary with a shell script, we:
- gain the ability to run pg_config easily when cross-compiling,
- can remove the fake pg_config in the default output,
- can remove the pg_config wrapper script dealing with special cases.
Some 20 years ago, pg_config *was* a shell script upstream, too. It was
changed to a binary, when it was made "relocatable", so it would return
paths depending on the location of the "postgres" binary. However, this
is exactly the thing that just hurts us in nixpkgs - we don't want those
paths to change, we want them to always point at the right outputs. By
writing the script ourselves, this becomes a lot less painful.
This approach means more lines of codes, but all of them are dead simple
and we have a lot less complexity overall.
Additionally, pg_config is now made a separate derivation, only exposed
as "postgresql.pg_config". This has the nice side-effect, that all users
of postgresql and libpq in nixpkgs must be very *explicit* about their
dependency on pg_config. This gives a lot more visibility into the state
of affairs regarding pkg-config support for libpq, which ultimately is
the much better solution.
2025-03-10 19:35:50 +01:00
|
|
|
passthru.pg_config = buildPackages.callPackage ./pg_config.nix {
|
|
|
|
inherit (finalAttrs) finalPackage;
|
|
|
|
};
|
|
|
|
|
2024-11-23 23:36:23 +01:00
|
|
|
meta = {
|
|
|
|
inherit (postgresql.meta)
|
|
|
|
homepage
|
|
|
|
license
|
|
|
|
teams
|
|
|
|
platforms
|
|
|
|
;
|
|
|
|
description = "C application programmer's interface to PostgreSQL";
|
|
|
|
changelog = "https://www.postgresql.org/docs/release/${finalAttrs.version}/";
|
|
|
|
pkgConfigModules = [ "libpq" ];
|
|
|
|
};
|
|
|
|
})
|