pkgsStatic.postgresql: fix build#345289
Conversation
e176720 to
17abff5
Compare
I hope that we don't need any regular rebuilds and only affect the static build, that's why I targeted master. If my latest fix doesn't do that, yet, I will look at the eval diff - could only be some whitespace in the script or so. |
17abff5 to
d578a79
Compare
d578a79 to
53b64d8
Compare
|
Would be good to understand what's wrong with the broken dependencies. Are they not compatible with being built statically in some fundamental way? If so, that should be marked in badPlatforms (see e.g. systemd), and then we should use lib.meta.availableOn rather than using an explicit isStatic check, so that platform info for those dependents can have a single source of truth. |
They both build fine in pkgsStatic, but PostgreSQL in combination doesn't. (Edit: I will dig out the error messages and add them as comments or so, let me see) |
53b64d8 to
128d27c
Compare
|
Tried to build with each of (icu, linux-pam) and put the error messages into a comment. I also tried some variations of |
Done. |
Ma27
left a comment
There was a problem hiding this comment.
Good enough for me now.
But if the server part is inherently broken on static builds, would it make sense to entirely skip the build? Haven't checkout how good this is doable though.
I think it would be more invasive to skip the build than I'd want to go at this stage. I just tried, but one thing leads to the next and it will result in quite a few I'd rather move towards a separate |
There was a problem hiding this comment.
This probably needs the following in its .pc file (upstream), if you're interested in fixing it:
Requires.private: audit
There was a problem hiding this comment.
Given it's autotools, something like this: rockdaboot/libpsl#246
There was a problem hiding this comment.
I'll have a look, but I'm not sure how useful that would be. I just looked and pkgsStatic.linux-pam contains only static libraries. But AFAICT, PAM is built around the idea of loading those authentication modules as shared libraries at run-time, depending on config. You'd probably have to link whatever authentication module you're going to use statically into the binary as well, but I'm not sure whether PAM would actually make use of that and how you'd configure it in that case.
Maybe it's a "linux-pam inherently doesn't make sense in pkgsStatic" as you earlier asked for, despite it being built fine on it's own.
There was a problem hiding this comment.
3 weeks ago, upstream merged a PR to build with meson. meson generally generates better .pc files. So it might be worth trying that.
There was a problem hiding this comment.
A new version of linux-pam was released, which only supports meson. I wasn't able to make that work, yet, so couldn't try whether that would improve this static build. Something for another day.
There was a problem hiding this comment.
Work at all or work with postgres?
There was a problem hiding this comment.
Couldn't make linux-pam build with meson, so was not able to update linux-pam itself in the first place. I never got to testing with postgres.
There was a problem hiding this comment.
Couldn't make linux-pam build with meson, so was not able to update linux-pam itself in the first place.
I can push my intermediate state of that, if you're interested.
There was a problem hiding this comment.
For icu, there has been a PR merged a week ago which adds some Requires.private and Libs.private to their pkg config files.
So maybe once this is available to us, this will be possible.
There was a problem hiding this comment.
Might be worth backporting now so we remember. (But doesn't have to block this PR even if we do.)
There was a problem hiding this comment.
I just tried this... but there is something odd going on. Those .private modifiers are only added for shared linking, not when linking statically. This is kind of the opposite of what we need. I'll try to dig deeper later and possibly raise this upstream.
128d27c to
c1bbf8c
Compare
|
Rebased, now it's simply a matter of disabling the new feature flags we have. Should be good to go, nothing more we can do here for now. |
|
The idea was to have a package that builds at least so that you can the |
Absolutely 🙈 Will look into it. |
The underlying problem was fixed as a side-effect of [1], for reasons unknown to me. In the current state, it's enough to disable a few breaking dependencies to make the build pass. Note, that this builds the full package, including backend. However, the backend is not working, yet: Loading shared modules, which PostgreSQL heavily depends is still broken. Further, all binaries in the default output, even client binaries such as psql, are currently dynamically linked against libpq.so. While the current autoconf based build system doesn't support changing this, this might be possible in the future with meson. However, not all is bad: Fixing the build allows using the static libpq.a library, which is probably the one thing that most users want from pkgsStatic.postgresql anyway. Resolves NixOS#191920 [1]: 7797728
c1bbf8c to
593bc6e
Compare
Right, so while I opened this PR against staging, I was still testing on master, where v16 was the default. This only breaks for v17, where we added new tools for building the docs: Seems like we should have technically added a Thus: I enabled strictDeps and added libxml2 as a nativeBuildInput. This should fix it and prevent regressions. |
593bc6e to
6547f93
Compare
6547f93 to
a77adf3
Compare
The underlying problem was fixed as a side-effect of 7797728, for reasons unknown to me. In the current state, it's enough to disable a few breaking dependencies to make the build pass.
Note, that this builds the full package, including backend. However, the backend is not working, yet: Loading shared modules, which PostgreSQL heavily depends is still broken. Further, all binaries in the default output, even client binaries such as psql, are currently dynamically linked against libpq.so. While the current autoconf based build system doesn't support changing this, this might be possible in the future with meson.
However, not all is bad: Fixing the build allows using the static libpq.a library, which is probably the one thing that most users want from
pkgsStatic.postgresqlanyway.Resolves #191920
Note: I also experimented with a meson-based static build, only to then notice that autoconf works with the basics as well. Making the switch to meson eventually should make things better, though: I was able to build a working backend, too, at least enough to run basic test suites for postgresql drivers with this. We can't fully switch to meson as a build system for 16 or 17, yet, because JIT will not work correctly. The meson build system doesn't build the required bitcode files, yet.
Things done
nix.conf? (See Nix manual)sandbox = relaxedsandbox = truenix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)Add a 👍 reaction to pull requests you find important.