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.

Sign up for GitHub

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

Jump to bottom

openvswitch: fix cross-compilation #68895

Closed
wants to merge 1 commit into from
Closed

openvswitch: fix cross-compilation #68895

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 2 additions & 3 deletions pkgs/os-specific/linux/openvswitch/default.nix
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -17,9 +17,8 @@ in stdenv.mkDerivation rec {

kernel = optional (_kernel != null) _kernel.dev;

nativeBuildInputs = [ pkgconfig ];
buildInputs = [ makeWrapper utillinux openssl libcap_ng python27
perl procps which ];
nativeBuildInputs = [ pkgconfig openssl python27 perl which ];
buildInputs = [ makeWrapper utillinux openssl libcap_ng python27 procps ];

configureFlags = [
"--localstatedir=/var"
Expand Down
2 changes: 1 addition & 1 deletion pkgs/top-level/all-packages.nix
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -5298,7 +5298,7 @@ in
opentracing-cpp = callPackage ../development/libraries/opentracing-cpp { };

openvswitch = callPackage ../os-specific/linux/openvswitch {
openssl = openssl_1_0_2;
openssl = __splicedPackages.openssl_1_0_2;
Copy link
Member

Choose a reason for hiding this comment

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

/cc @Ericson2314

Copy link
Member

Choose a reason for hiding this comment

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

Is __splicedPackages targetPackages?

Copy link
Member

Choose a reason for hiding this comment

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

Or in other words, what does this change fixes?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

openssl_1_0_2 is just a derivation, whereas __splicedPackages.openssl_1_0_2 is augmented with attributes referring to that derivation for other (host, target) pairs. For example, __splicedPackages.openssl_1_0_2.nativeDrv refers to buildPackages.openssl_1_0_2.

See this comment for more detail: #68967 (comment)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

openvswitch/default.nix refers to openssl in both .nativeBuildInputs and .buildInputs. In the case of cross-compilation, mkDerivation accesses spliced attributes for elements of these lists. So, the openssl argument to openvswitch/default.nix must be spliced.

callPackage automatically uses spliced packages. However, the packages in scope in top-level/all-packages.nix are not spliced. So, to pass in a spliced openssl_1_0_2, we must explicitly refer to __splicedPackages.openssl_1_0_2.

This may not be the best solution to cross-compiling this particular package, but similar situations appear throughout Nixpkgs. I think it's worth considering how we should be handling them.

Copy link
Member

Choose a reason for hiding this comment

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

Ok. @Ericson2314 seems to prefer buildPackages though.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I agree with them. This case is a bit more complicated because openvswitch really takes two distinct openssl derivations as parameters, one for the build and one to link against, which are different in the case of cross compilation. They suggest what seems like the most sensible solution right now: #68900 (comment). That is, to explicitly allow the overriding of both derivations separately.

};

optipng = callPackage ../tools/graphics/optipng {
Expand Down