Skip to content
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

lvm2: support static compilation #96014

Closed
wants to merge 1 commit into from

Conversation

baloo
Copy link
Member

@baloo baloo commented Aug 22, 2020

Motivation for this change

Fixup compilation of lvm2 on musl.

Things done
  • Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Determined the impact on package closure size (by running nix path-info -S before and after)
  • Ensured that relevant documentation is up to date
  • Fits CONTRIBUTING.md.

@baloo baloo changed the title lvm2: support static comilation lvm2: support static compilation Aug 22, 2020
@baloo baloo force-pushed the baloo/lvm2/static-compilation branch from 13321be to 5b6c5ba Compare August 22, 2020 17:27
@ofborg ofborg bot requested review from ajs124 and 7c6f434c August 22, 2020 18:51
@@ -84,6 +85,7 @@ stdenv.mkDerivation rec {
url = "https://git.alpinelinux.org/aports/plain/main/lvm2/mlockall-default-config.patch?h=3.7-stable&id=31bd4a8c2dc00ae79a821f6fe0ad2f23e1534f50";
sha256 = "1ivbj3sphgf8n1ykfiv5rbw7s8dgnj5jcr9jl2v8cwf28lkacw5l";
})
./no-dynamic.patch
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where does this patch come from? Was it submitted upstream? Can it be fetched from there?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I rewrote the patch to a version I'm much more confident sending upstream. I sent the patch upstream (lvm-devel@ mailiing list but my patch does not show up in the archive (yet?)), I'll keep an eye on it and update according to comments made by upstream.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@baloo baloo force-pushed the baloo/lvm2/static-compilation branch from 5b6c5ba to 3860c52 Compare August 22, 2020 21:38
@baloo baloo force-pushed the baloo/lvm2/static-compilation branch from 3860c52 to bb9c1e5 Compare August 23, 2020 00:49
@@ -31,11 +31,12 @@ stdenv.mkDerivation rec {
"--enable-pkgconfig"
"--with-default-locking-dir=/run/lock/lvm"
"--with-default-run-dir=/run/lvm"
"--with-systemdsystemunitdir=${placeholder "out"}/lib/systemd/system"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why was this moved to udev != null. Is that "codepath" even used anywhere in nixpkgs?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I use it on static builds (one I use in initrd, to save space). Building udev/systemd static is ... quite challenging :) (or all the dependencies it pulls)

return 14;
close (fd);
+ free (data);
+ free (data3);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this mean there was a memory leak upstream? Not sure I like this being silently in the middle of allow-static-build patch…

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

configure (the output from autoconf) is commited in the repository. I ran autoconf, with a slightly more recent version than last maintainer of that file did (more than a year ago).
It looks like it's code that tests features from the environment to detect them, as autoconf usually does. This looks like fixes further upstream in autoconf.

Just like the runstate parameter additions, I think they can safely be ignored.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, memory leak in a temporary configure executable 🤷

Copy link
Member

@7c6f434c 7c6f434c left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code looks fine to me

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants