| 11 Jun 2024 |
Alexandros Liarokapis | Hmm yea I guess it depends on the encoding | 12:44:46 |
Alexandros Liarokapis | Probably only works for c strings | 12:44:52 |
Minijackson | if the path are shorter, it could be padded with /, but seems hacky x) | 12:44:57 |
Minijackson | In reply to @aliarokapis:matrix.org Probably only works for c strings even then, depending on compiler optimisations and other factors, the length of the string might be assumed | 12:45:33 |
Alexandros Liarokapis | Padding with null strings is also possible | 12:45:34 |
Alexandros Liarokapis | * Padding with null chars is also possible | 12:45:49 |
Minijackson | In reply to @aliarokapis:matrix.org Padding with null chars is also possible not sure, if the compiler optimises printf("some string") to write(stdout, "some string", 11), replacing some string with something shorter but null padded will print null bytes to stdout | 12:46:43 |
nbp | In reply to @aliarokapis:matrix.org Converting longer paths to shorter relative ones should work No, Pascal for example encode the length next to the string. | 12:53:00 |
nbp | Some compilers could bake-in strlen of constants at compile time. | 12:55:12 |
willbush | infinisil: Philip Taron (UTC-8): I've been kinda wanting a place to share and discuss Rust blog posts / news with you guys. Any ideas? | 13:08:56 |
@aloisw:kde.org | In reply to @nbp:mozilla.org The replaceDependencies is the closest thing there is to replacing raw path to the nix store by another one in the nix-store, but beware that if the version changes from 0.4.0 to 0.4.0a this would cause a lot of issues. This is why it enforces the same length already. | 14:10:04 |
Philip Taron (UTC-8) | I'm in most of the Matrix rooms, and on NixOS discourse. If you want something else, my email is philip.taron@gmail.com 🙂 | 14:57:17 |
| 14 Jun 2024 |
infinisil | Weekly office hour now :) https://meet.jit.si/nixpkgs-architecture | 17:57:50 |
infinisil | Cc willbush Philip Taron (UTC-8) Dominic Mills | 17:59:13 |
infinisil | With Will and Dominic in the call I created a bunch of PRs improve some misc stuff in Nixpkgs, mostly churning this issue down :) | 19:50:53 |
infinisil | If anybody wants to help out, feel free to fix more cases mentioned in that issue :D | 19:51:31 |
| 17 Jun 2024 |
Philip Taron (UTC-8) | I'm thinking up ways to test https://github.com/NixOS/nixpkgs/pull/315654. There aren't any tests of nixos-option that I can see right now. | 23:04:27 |
Philip Taron (UTC-8) | * I'm thinking up ways to test https://github.com/NixOS/nixpkgs/pull/313497. There aren't any tests of nixos-option that I can see right now. | 23:04:49 |
| 18 Jun 2024 |
Philip Taron (UTC-8) | I currently find that if I try to ask for recursive output on my configuration, I end up getting an absolutely inscrutable error about list index 0 is out of bounds in lib/generators.nix toPretty method. | 00:07:04 |
Philip Taron (UTC-8) | In reply to @philiptaron:matrix.org I currently find that if I try to ask for recursive output on my configuration, I end up getting an absolutely inscrutable error about list index 0 is out of bounds in lib/generators.nix toPretty method. It turns out that this was Nix deciding not to show me that the actual error was in a let block in nixos/modules/tasks/filesystems.nix. I opened https://github.com/NixOS/nixpkgs/pull/320846 to fix this. | 18:39:14 |
| 19 Jun 2024 |
Alexandros Liarokapis | the rust infra has this definition:
linkerForTarget = if shouldUseLLD pkgsTargetTarget.stdenv.targetPlatform
&& !pkgsTargetTarget.stdenv.cc.bintools.isLLVM # whether stdenv's linker is lld already
then "${pkgsBuildTarget.llvmPackages.bintools}/bin/${pkgsTargetTarget.stdenv.cc.targetPrefix}ld.lld"
else ccForTarget;
when cross compiling to arm-none-eabihf (target = "thumbv7em-none-eabihf") this ends up picking arm-none-eabi-gcc as CARGO_TARGET_*_LINKER which then fails due to being passed flags like --gc-sections, -flavor, --as-needed, eh-frame-hdr and similar.
| 16:47:25 |
Alexandros Liarokapis | * the rust infra has this definition:
linkerForTarget = if shouldUseLLD pkgsTargetTarget.stdenv.targetPlatform
&& !pkgsTargetTarget.stdenv.cc.bintools.isLLVM # whether stdenv's linker is lld already
then "${pkgsBuildTarget.llvmPackages.bintools}/bin/${pkgsTargetTarget.stdenv.cc.targetPrefix}ld.lld"
else ccForTarget;
when cross compiling to arm-none-eabihf (target = "thumbv7em-none-eabihf") this ends up picking arm-none-eabihf-gcc as CARGO_TARGET_*_LINKER which then fails due to being passed flags like --gc-sections, -flavor, --as-needed, eh-frame-hdr and similar.
| 16:47:51 |
Alexandros Liarokapis | changing it to arm-none-eabihf-ld works. | 16:48:13 |
Alexandros Liarokapis | Redacted or Malformed Event | 16:50:19 |
Alexandros Liarokapis | taking about https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-support/rust/lib/default.nix | 16:52:02 |
Alexandros Liarokapis | maybe platform.isNone should be added as a shouldUseLLD check ? | 16:52:19 |
| 20 Jun 2024 |
Alexandros Liarokapis | in which cases is using ccForTarget correct? mainly for the clang environments ? | 13:01:09 |
| 21 Jun 2024 |
| @jade_:matrix.org left the room. | 05:15:48 |
Alyssa Ross | Using LLD on aarch64 static is a hack around a rustc bug. It wasn't the intention to force lld on rustc for any architecture long term. | 07:25:45 |
Alyssa Ross | If Rust for some reason doesn't expect to pass flags through cc on that target, we'd probably need some other check to tell it to use ld | 07:26:19 |