-
-
Notifications
You must be signed in to change notification settings - Fork 14.7k
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
stdenv: don't set NIX_LIB*_IN_SELF_RPATH by default #223861
Merged
Merged
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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'm afraid it's not that easy and depends on specific ports.
In theory non-multilib targets should just use
lib
. In practice what is a multilib has a moot definition: for examplex86_64-linux-glibc
is always multilib whilex86_64-linux-musl
is (or, should be) never multilib.You can see remnants of multilib in
gcc
itself:Sometimes packages are diligent enough to have
lib -> lib64
symlink (or the other way around). Sometimes they are not.The question here is: What API do we expect for
nixpkgs
to provide and packages to use for non-multilib? Is it alwayslib
or something else (lib64
)? Today we do both withlib64
being a canonical path.This change effectively says
lib64
is not considered anymore as a searchpath.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 think I follow, and quite possibly this change is too ambitious. My naïve thinking was that given the explicit dependencies of Nix, there shouldn't ever be multiple library search paths, only one set of paths per target.
However, assuming nixpkgs wants to keep the
NIX_LIB*_IN_SELF_RPATH
API, this change also fixes what I consider a genuine bug: thatNIX_LIB*_IN_SELF_RPATH
are set according to the build platform, not the target platform.See #221350 for an example where the builder platform (x86_64-linux vs aarch64-linux) decides whether
NIX_LIB*_IN_SELF_RPATH
is set, not the target platform which is the same (and non-multilib).So, can I move the setting of
NIX_LIB*_IN_SELF_RPATH
somewhere that depends on the target/host platform?pkgs/stdenv/linux/default.nix
is itself prefixed withassert crossSystem == localSystem;
and thus cannot decide whether to set
NIX_LIB*_IN_SELF_RPATH
. No?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.
Cross-compilation case is a great point! I'll spend some time today to understand how
nixpkgs
plumbsrpath
details there and get back.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.
Is it fair to say
NIX_LIB*_IN_SELF_RPATH
should only be set formultiStdenv
? If so, the variables could be set conditionally there.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.
Ideally (if non-multilib environment used
lib
everywhere consistently) - yes. In practice I don't think we are there yet. We probably want bothlib
andlib64
to still be pulled in. Normally I would expectNIX_LDFLAGS
to apply to host toolchains (andNIX_LDFLAGS_FOR_BUILD
/NIX_LDFLAGS_FOR_TARGET
be disambiguating variables).On the other hand looking at the history far back it was added before cross-compilation was a well-supported target: d9213df . It probably outlived it's purpose and we have many other ways to influence the driver.
Let's try your change as is and see if it works on multilib.
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.
Nice, thank you.
By "other means to influence the driver", do you mean the corresponding (and only) users of the
NIX_LIB*_IN_SELF_RPATH
,nixpkgs/pkgs/stdenv/generic/setup.sh
Lines 314 to 319 in 2ba1f86
should be removed as well?
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.
Yeah, let's remove those as well.
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.
Done.