| 19 Nov 2024 |
p14 | Seems like it would be potentially quite a substantial nixpkgs rearchitecting to be able to run tests in a separate derivation, or do you see a route which would not require this? | 19:37:53 |
emily | yes, this whole thing would be very substantial :) | 19:38:54 |
emily | it's probably not something we could realistically migrate to, it's more very good ideas for the next thing that comes along | 19:39:12 |
emily | the alternative is to fold checks into the derivation that does the relinking which would be not quite as burdensome | 19:39:33 |
emily | but reduce the parallelism advantages | 19:39:37 |
emily | (and it's much more installCheckPhase-oriented than checkPhase) | 19:39:51 |
| 20 Nov 2024 |
| Inayet removed their profile picture. | 00:59:04 |
Randy Eckenrode | Posting this here too. I reduced the number of Clangs Darwin needs to cross-compile. | 19:28:41 |
Randy Eckenrode | https://github.com/NixOS/nixpkgs/pull/357633 | 19:28:42 |
| truby joined the room. | 21:08:45 |
| 21 Nov 2024 |
Tristan Ross | https://github.com/NixOS/nixpkgs/pull/348192 might be good for someone to look at this, I'll fix the conflicts soon. | 15:00:17 |
| 22 Nov 2024 |
| Morgan (@numinit) joined the room. | 17:50:23 |
| 23 Nov 2024 |
Tristan Ross | https://github.com/NixOS/nixpkgs/pull/335023 anyone around to look at this? I kinda want to use an LLVM kernel but this PR is blocking that. | 05:30:46 |
emily | while I like the end result, I'm also sceptical of the as32bit/as64bit thing. like is there any AArch64 hardware that implements ARMv5? some of these don't make sense to couple to me | 05:33:29 |
emily | like why does it condition on just cross-bit size when presumably the same problems would apply to other cross scenarios? | 05:33:47 |
emily | AFAICT cross shouldn't care if the build and host architectures are "similar" ISAs | 05:34:31 |
Tristan Ross | In reply to @emilazy:matrix.org while I like the end result, I'm also sceptical of the as32bit/as64bit thing. like is there any AArch64 hardware that implements ARMv5? some of these don't make sense to couple to me I'm not sure. | 05:34:35 |
emily | they should be independent | 05:34:36 |
emily | I think what you really want is https://github.com/NixOS/nixpkgs/pull/354622. | 05:34:54 |
Tristan Ross | The problem is I needed a way to figure out it was compiling for 32-bit or 64-bit | 05:35:22 |
Tristan Ross | And then apply the specific hardening options which are applicable | 05:35:34 |
Tristan Ross | In reply to @emilazy:matrix.org I think what you really want is https://github.com/NixOS/nixpkgs/pull/354622. I'm kinda skeptical if that does fix the problem, would it remove incompatible hardening options when cc-wrapper is compiling a 32-bit object with a 64-bit stdenv? | 05:36:48 |
emily | it would completely separate host and build hardening flags | 05:37:03 |
emily | why would incompatible hardening flags be getting set at all? | 05:37:11 |
emily | only due to build–host–target confusion | 05:37:18 |
emily | separating them out fully is the solution, not hacking around it by trying to filter things out after the fact | 05:37:28 |
Tristan Ross |
As the title says, this disables incompatible hardening options when cross compiling between the same ISA but different bit size. This prevents the issue of the zerocallregs hardening option from being used when using clang to build Linux and Linux is building for aarch64 but builds vdso32.
From my PR
| 05:37:35 |
Tristan Ross | zerocallregs isn't supported in 32-bit but it is in 64-bit | 05:37:58 |
Tristan Ross | vdso32 is compiled as 32-bit | 05:38:07 |
emily | yes but we only set hardening flags that are meant to be supported by the platform | 05:38:16 |