-
-
Notifications
You must be signed in to change notification settings - Fork 14.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
pkgsStatic.postgresql: fix build #345289
pkgsStatic.postgresql: fix build #345289
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me, thank you!
However, this will need to target staging.
@alyssais do you want to take a look? Would wait a few days with merging.
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 |
# /nix/store/3s55icpsbc36sgn7sa8q3qq4z6al6rlr-linux-pam-static-x86_64-unknown-linux-musl-1.6.1/lib/libpam.a(pam_audit.o): | ||
# in function `pam_modutil_audit_write':(.text+0x571): | ||
# undefined reference to `audit_close' | ||
++ lib.optionals (stdenv'.hostPlatform.isLinux && !stdenv'.hostPlatform.isStatic) [ "--with-pam" ] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Given it's autotools, something like this: rockdaboot/libpsl#246
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, that should do it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Work at all or work with postgres?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
# Building with icu in pkgsStatic gives tons of "undefined reference" errors like this: | ||
# /nix/store/452lkaak37d3mzzn3p9ak7aa3wzhdqaj-icu4c-74.2-x86_64-unknown-linux-musl/lib/libicuuc.a(chariter.ao): | ||
# (.data.rel.ro._ZTIN6icu_7417CharacterIteratorE[_ZTIN6icu_7417CharacterIteratorE]+0x0): | ||
# undefined reference to `vtable for __cxxabiv1::__si_class_type_info' | ||
(lib.withFeature (!stdenv'.hostPlatform.isStatic) "icu") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.postgresql
anyway.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 = relaxed
sandbox = true
nix-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.