Nixpkgs Stdenv - Public Room Timeline

	Nixpkgs Stdenv	224 Members
		74 Servers

Load older messages

Sender	Message	Time
3 May 2025
Randy Eckenrode	* It would also fix the following warnings when SwiftPM invokes Clang. `clang: warning: overriding '-mmacos-version-min=11.3' option with '-target arm64-apple-macosx10.13'`	17:15:07
4 May 2025
aleksana 🏳️‍⚧️ (force me to bed after 18:00 UTC)	Two PRs aiming to fix "cross compilation" between different march https://github.com/NixOS/nixpkgs/pull/403549 https://github.com/NixOS/nixpkgs/pull/403960	07:08:19
Morgan (@numinit)	Randy Eckenrode: Hey there, Darwin question for you. ponyc does this and we have to patch: https://github.com/NixOS/nixpkgs/blob/master/pkgs/by-name/po/ponyc/fix-darwin-build.patch However, hydra is complaining about: ld: warning: directory not found for option '-L/nix/store/6fg11q5s4xpgfpvps1hy7w9vjhfl14mx-Libsystem-11.0/lib' ld: library not found for -lSystem Feel like I'm just missing something stupid here.	21:58:08
Randy Eckenrode	Don’t use `darwin.Libsystem`. It’s an empty stub with nothing in it. It’s scheduled for removal too. If you need to find the location of `libSystem.tbd`, it’s in `$SDKROOT/usr/lib`.	22:00:16
Morgan (@numinit)	Gotcha, that explains it	22:01:12
Morgan (@numinit)	Thanks, I'll give that a shot	22:01:27
Morgan (@numinit)	Aha, solved it. Thank you	23:38:43
9 May 2025
p14	Wait, does this make sense? https://github.com/NixOS/nixpkgs/blob/907e98d6cc08e3261b63e3f8d2831841817b0041/pkgs/build-support/bintools-wrapper/ld-wrapper.sh#L84-L95 `NIX_LDFLAGS_@suffixSalt@` and `NIX_LDFLAGS_BEFORE_@suffixSalt@` are gated on the link type being empty. But NIX_LDFLAGS_AFTER_@suffixSalt@ is not. An oversight, I presume? I just hit it with a bit of confusion as to why my override was not having effect in a static build (where the link type is set). It also looks to me like any tests should be using $linkType, per https://github.com/NixOS/nixpkgs/blob/907e98d6cc08e3261b63e3f8d2831841817b0041/pkgs/build-support/bintools-wrapper/ld-wrapper.sh#L32	06:01:05
p14	* Wait, does this make sense? https://github.com/NixOS/nixpkgs/blob/907e98d6cc08e3261b63e3f8d2831841817b0041/pkgs/build-support/bintools-wrapper/ld-wrapper.sh#L84-L95 `NIX_LDFLAGS_@suffixSalt@` and `NIX_LDFLAGS_BEFORE_@suffixSalt@` are gated on the link type being empty. But `NIX\_LDFLAGS\_AFTER\_@suffixSalt@` is not. An oversight, I presume? I just hit it with a bit of confusion as to why my override was not having effect in a static build (where the link type is set). It also looks to me like any tests should be using $linkType, per https://github.com/NixOS/nixpkgs/blob/907e98d6cc08e3261b63e3f8d2831841817b0041/pkgs/build-support/bintools-wrapper/ld-wrapper.sh#L32	06:01:27
p14	* Wait, does this make sense? https://github.com/NixOS/nixpkgs/blob/907e98d6cc08e3261b63e3f8d2831841817b0041/pkgs/build-support/bintools-wrapper/ld-wrapper.sh#L84-L95 `NIX_LDFLAGS_@suffixSalt@` and `NIX_LDFLAGS_BEFORE_@suffixSalt@` are gated on the link type being empty. But `NIX_LDFLAGS_AFTER_@suffixSalt@` is not. An oversight, I presume? I just hit it with a bit of confusion as to why my override was not having effect in a static build (where the link type is set). It also looks to me like any tests should be using $linkType, per https://github.com/NixOS/nixpkgs/blob/907e98d6cc08e3261b63e3f8d2831841817b0041/pkgs/build-support/bintools-wrapper/ld-wrapper.sh#L32	06:01:35
p14	It looks to me like the second condition (`$linkType` == dynamic) doesn't especially make sense to be gated by `if [ -z "${NIX_LINK_TYPE_@suffixSalt@:-}" ]`, so it doesn't belong nested in that conditional. And I don't see a good reason to gate the availability of 'NIX_LDFLAGS_*` on the link type.	06:03:34
p14	* Wait, does this make sense? https://github.com/NixOS/nixpkgs/blob/907e98d6cc08e3261b63e3f8d2831841817b0041/pkgs/build-support/bintools-wrapper/ld-wrapper.sh#L84-L95 `NIX_LDFLAGS_@suffixSalt@` and `NIX_LDFLAGS_BEFORE_@suffixSalt@` are gated on the link type being empty. But `NIX_LDFLAGS_AFTER_@suffixSalt@` is not. An oversight, I presume? I just hit it with a bit of confusion as to why my override was not having effect in a static build (where the link type is set to static, but $NIX_LINK_TYPE is empty). It also looks to me like any tests should be using $linkType, per https://github.com/NixOS/nixpkgs/blob/907e98d6cc08e3261b63e3f8d2831841817b0041/pkgs/build-support/bintools-wrapper/ld-wrapper.sh#L32	06:04:24
p14	Oh, meanwhile, NIX_LDFLAGS_BEFORE are also handled in the cc-wrapper, and added as -Wl, to add to the confusion. And the actual reason my flags weren't taking effect was because I had the wrong suffixSalt in effect.	06:17:29
10 May 2025
p14	I'm messing with my own stdenvStages as an experiment and to learn about the stdenv. I've hit upon a fun problem. If I add my own stage which makes use of a suffixed compiler from an earlier stage, the wrapped compiler is suffixed but the unwrapped compiler is not. This line: https://github.com/NixOS/nixpkgs/blob/1a5bd697adecf27385b69352485baa52a6e02fe9/pkgs/build-support/cc-wrapper/setup-hook.sh#L93 Ends up putting the $CC_FOR_BUILD's unwrapped compiler in the $PATH before the host compiler. So `which $CC` resolves as the unwrapped $CC_FOR_BUILD instead of $CC's wrapped compiler. This works fine for most standard scenarios, I think, because normally you'd be using some native (and unsuffixed) compiler as $CC_FOR_BUILD (=gcc) and the $CC would be set to some suffixed compiler. So if `$PATH = cc-for-build:cc-for-build-unwrapped:cc:cc-unwrapped`; the path search works fine because it find the suffixed compiler in `:cc:`. Not sure exactly how to solve it; I don't yet see why you'd want the unwrapped compiler in the path at all.	12:05:51
p14	* I'm messing with my own stdenvStages as an experiment and to learn about the stdenv. I've hit upon a fun problem. If I add my own stage which makes use of a suffixed compiler from an earlier stage, the wrapped compiler is suffixed but the unwrapped compiler is not. This line: https://github.com/NixOS/nixpkgs/blob/1a5bd697adecf27385b69352485baa52a6e02fe9/pkgs/build-support/cc-wrapper/setup-hook.sh#L93 Ends up putting the $CC_FOR_BUILD's unwrapped compiler in the $PATH before the host compiler. So `which $CC` resolves as the unwrapped $CC_FOR_BUILD instead of $CC's wrapped compiler. This works fine for most standard scenarios, I think, because normally you'd be using some native (and unsuffixed) compiler as $CC_FOR_BUILD (=gcc) and the $CC would be set to some suffixed compiler. So if `$PATH = cc-for-build:cc-for-build-unwrapped:cc:cc-unwrapped`; the path search works fine because it finds the suffixed compiler in `:cc:`. Not sure exactly how to solve it; I don't yet see why you'd want the unwrapped compiler in the path at all.	12:06:16
p14	* I'm messing with my own stdenvStages as an experiment and to learn about the stdenv. I've hit upon a fun problem. If I add my own stage which makes use of a target-prefixed compiler from an earlier stage, the wrapped compiler is prefixed but the unwrapped compiler is not. This line: https://github.com/NixOS/nixpkgs/blob/1a5bd697adecf27385b69352485baa52a6e02fe9/pkgs/build-support/cc-wrapper/setup-hook.sh#L93 Ends up putting the $CC_FOR_BUILD's unwrapped compiler in the $PATH before the host compiler. So `which $CC` resolves as the unwrapped $CC_FOR_BUILD instead of $CC's wrapped compiler. This works fine for most standard scenarios, I think, because normally you'd be using some native (and unprefixed) compiler as $CC_FOR_BUILD (=gcc) and the $CC would be set to some prefixed compiler. So if `$PATH = cc-for-build:cc-for-build-unwrapped:cc:cc-unwrapped`; the path search works fine because it finds the prefixed compiler in `:cc:`. Not sure exactly how to solve it; I don't yet see why you'd want the unwrapped compiler in the path at all.	12:12:50
11 May 2025
trofi	Ideally wrappers should always expose prefixed binaries.	14:34:59
trofi	(like abandoned https://github.com/NixOS/nixpkgs/pull/181724)	14:35:49
Tristan Ross	In reply to @trofi:matrix.org (like abandoned https://github.com/NixOS/nixpkgs/pull/181724) Rip yeah, imo we should be closing abandoned PR's because there's not really a point in leaving them open	15:04:17
Alyssa Ross	Is there a point in closing them?	15:06:07
Tristan Ross	Well if it's not going to be worked on anytime soon, why leave like a 2yo PR that has merge conflicts open?	15:07:18
emily	it was closed in 2022?	15:07:48
trofi	looking at the comment it broke meson-based builds on clang (and they used to work by accident by using a wrong compiler)	15:08:53
p14	But is there a good reason to put the unwrapped CC in the path? I have dropped it without ill effect and it does fix things ion my case.	17:17:03
emily	we don't but we do want prefixed compilers	17:18:55
emily	so the prefixed ones should probably be wrapped	17:19:10
p14	So, could https://github.com/NixOS/nixpkgs/blob/1a5bd697adecf27385b69352485baa52a6e02fe9/pkgs/build-support/cc-wrapper/setup-hook.sh#L92-L94 and https://github.com/NixOS/nixpkgs/blob/1a5bd697adecf27385b69352485baa52a6e02fe9/pkgs/build-support/bintools-wrapper/setup-hook.sh#L39-L41 be dropped. In light of the commit message here https://github.com/NixOS/nixpkgs/pull/182385/commits/e682dd84cff5d2420fcc0a40508557477f6cc9d3 which comments that it was unknown why there were in the path (but the answer is linked above). Now it is found, can we delete it? :)	18:42:09
p14	I'm thinking that essentially if there is some binary provided by the compiler and it's not symlinked into the wrapper, that is a bug.	18:43:42
p14	While messing with the booting machinery I am hitting an odd thing where somehow a meson is creeping in which has an openmp dependency which creates an infinite cycle. Haven't debugged it yet. (clang -> tblgen -> cmake -> libarchive -> e2fsprogs -> fuse -> meson (from some other stage) -> openmp -> infinite cycle on clang). I guess I need to plug something into my stdenv overrides to prevent this.	18:54:42
trofi	`e2fsprogs -> fuse` can be broken by disabling `withFuse = false;`	18:56:41

Show newer messages

Back to Room ListRoom Version: 9