| 1 Nov 2021 |
 Alyssa Ross | We've been stuck for years because we've been stuck on it on Darwin, and everything uses LLVM on Darwin. | 09:19:43 |
 trofi | Oh, that makes sense.. I was very confused to see that mesa uses llvmPackages_latest (from llvm-12) and libclc (from llvm-11, hardcodes source version in .nix file). And libclc is built against llvmPackages libraries (llvm-7). | 09:33:20 |
| trofi | * Oh, that makes sense. I was very confused to see that mesa uses llvmPackages_latest (from llvm-12) and libclc (from llvm-11, hardcodes source version in .nix file). And libclc is built against llvmPackages libraries (llvm-7). | 09:33:39 |
| Alyssa Ross | the place to watch is https://github.com/NixOS/nixpkgs/pull/126411 | 09:36:23 |
 Domen Kožar | it's basically ready it's waiting on the next NixOS cycle (ironically, darwin is stuck due to linux, which is stuck due to darwin) | 18:27:11 |
| trofi | Sorry, I don't know how nixpkgs manages toolchain lifecycle :) Does cycle here mean NixOS release? Or just a staging->master merge? | 19:33:32 |
 sterni | nixos release | 19:33:48 |
| sterni | specifically upgrading LLVM from 7 to 11 is not possible anymore due to the feature freeze disallowing breaking changes on staging-next | 19:34:16 |
| sterni | it would have been fine if the PR would have been ready earlier | 19:34:29 |
| trofi | Ah, it's a matter of pre-release freeze. Otherwise, would it be fine to change major compiler version say, every 2 months in staging? (Not that they release that frequently). | 19:37:47 |
| Alyssa Ross | yes | 19:38:21 |
| Alyssa Ross | Redacted or Malformed Event | 19:38:31 |
| Alyssa Ross | as long as packages keep building | 19:38:56 |
| trofi | nod. Thank you! | 19:39:09 |
| sterni | shouldn't libexec be installed to $out/$bin? | 19:45:33 |
| trofi | probably rather $out/$lib. otherwise installing such a package would get internal tools (or their dir) into PATH. postfix or git should be good examples. | 19:51:04 |
| sterni | libexec is never in PATH? | 19:51:29 |
| trofi | I think it's never in PATH. https://www.gnu.org/prep/standards/html_node/Directory-Variables.html also says it's not for users. | 19:53:23 |
 @AleXoundOS:matrix.org | ldd gets removed when crosscompiling: https://github.com/NixOS/nixpkgs/blob/18b9519c0a887baa8648ce82c2f2c9d965be0690/pkgs/development/libraries/glibc/common.nix#L292
How can I get ldd then? | 20:37:10 |
| @AleXoundOS:matrix.org | * ldd gets removed from glibc bin output when crosscompiling: https://github.com/NixOS/nixpkgs/blob/18b9519c0a887baa8648ce82c2f2c9d965be0690/pkgs/development/libraries/glibc/common.nix#L292
How can I get ldd then? | 20:37:32 |
| sterni | hmmmm https://github.com/NixOS/nixpkgs/blob/fd70eae72fddf2f7e1556c7705d3ad4bb97cb551/pkgs/development/tools/build-managers/cmake/setup-hook.sh#L97 | 20:39:10 |
| sterni | John Ericson: for clang it would be a lot easier if CMAKE_LIBEXEC_DIR was in $out instead of $lib. A lot of tools depend on ../libexec/ccc-analyzer working and it would be annoying to add yet another patch for this | 20:40:00 |
| sterni | not sure if we should change it globally or just overriding the value passed here somehow makes more sense | 20:40:17 |
| sterni | In reply to @AleXoundOS:matrix.org
ldd gets removed from glibc bin output when crosscompiling: https://github.com/NixOS/nixpkgs/blob/18b9519c0a887baa8648ce82c2f2c9d965be0690/pkgs/development/libraries/glibc/common.nix#L292
How can I get ldd then? what do you need ldd for? | 20:40:35 |
| @AleXoundOS:matrix.org | In reply to @sternenseemann:systemli.org
what do you need ldd for? I need to get the list of all dynamic libraries linked (so that I keep only them on the target 16 MiB filesystem). But yeah, I know readelf can show dynamic libraries (but not recursively). I just thought I could quickly run ldd to observe the situation. | 20:44:10 |
| sterni | you may want to use nix-store --query --references <store path> for this purpose which shows you which nix store paths are referenced by the build result | 20:45:21 |
| sterni | this also accounts for data files and like hardcoded executable calls | 20:45:38 |
| sterni | also maybe nix-copy-closure is interesting for you for purpose of copying everything necessary from your build system to the host system | 20:46:04 |
| sterni | hm seems like glibc does weird stuff with ldd i. e. the installed ldd always runs on the build platform? | 20:47:04 |
| sterni | at least that is what it seems like from the comment | 20:47:20 |
