ehmry changed the topic of #nixos-exotic to: NixOS exotic platforms channel | https://github.com/NixOS/nixpkgs/labels/6.topic%3A%20exotic | https://github.com/nix-community/redoxpkgs | https://git.sr.ht/~ehmry/sigil | Keep NixOS weird
dckc has quit [Quit: ZNC 1.6.6+deb1ubuntu0.2 - http://znc.in]
dckc has joined #nixos-exotic
<qyliss> Ericson2314: does "Great!" mean "go ahead and merge, Alyssa"?
<Ericson2314> qyliss: sorry i was on my phone, and there is this terrible android bug where it stops respecting the cursor position
<Ericson2314> i was going to say squashing sounds good but I didn't want github to do it and to loose the notes in the commits
<Ericson2314> I'll go squash it now that I am back on desktop after al
<qyliss> alright :)
<qyliss> I've been trying to get aarch64-netbsd going today, but it's quite a slog
<Ericson2314> still, that's cool though
<Ericson2314> qyliss: it looks like you checked all the ones where the hash didn't change?
<qyliss> yeah Idid
<Ericson2314> great, thanks
<Ericson2314> pushed the squash one
<qyliss> awesome
<qyliss> glad to have that over :)
<qyliss> oh, but you didn't merge yet
<qyliss> I see
<qyliss> waiting for ofborg?
<Ericson2314> yeahh
<qyliss> I've been meaning to write a script for that
<qyliss> wonder how many gccs I've built today...
<qyliss> grr, still C compiler cannot create executables
<qyliss> think I'll give up on aarch64-netbsd for today
<Ericson2314> are you cross compiling from x86_64-linux or aarch64-linux?
<qyliss> x86_64-linux
<qyliss> and I'm using NetBSD's binutils fork, because upstream doesn't support the target arch yet
<Ericson2314> qyliss: oh huh what is missing in usteam binutils?
<Ericson2314> was it a sort of relocation?
<qyliss> no, it doesn't even recognise the architecture
<qyliss> maybe I should try extracting NetBSD's patches, instead of using their fork
<qyliss> but not sure how possible that is
<Ericson2314> oh that's weird
<Ericson2314> I figured binutils wouldn't even care about the OS that muchc
<Ericson2314> * I figured binutils wouldn't even care about the OS that much
<qyliss> I suppose I could try just adding it to the list of supported targets and doing nothing else
<qyliss> but fwiw there do seem to have been quite a few aarch64-specific changes in the NetBSD aarch64 fork
<qyliss> *binutils fork
<qyliss> Ericson2314: other problem is that gcc support for aarch64-netbsd was only introduced in GCC 10, but in Nixpkgs we're stuck on GCC 9 for aarch64
<Ericson2314> Huh ok
<Ericson2314> I should go make a patch to normalize some of the version picking stuff
<qyliss> I don't know what's wrong with GCC 10 on aarch64 in general
<qyliss> #108200
<qyliss> oh no bot in here
<qyliss> Ericson2314: NetBSD developer friend helped me figure out the dynamic linking problem
<qyliss> [Requesting program interpreter: /nix/store/jmxnclcdcwkczmqz9i5jipqlgd5kh03j-libc-netbsd-9.1-x86_64-unknown-netbsd/libexec/ld.elf_so]
<Ericson2314> qyliss: oh cool!
<Ericson2314> and I hope some netbsd devs are a little interested in this :)
<qyliss> at least one is
<qyliss> i think they're probably the only one who knows about it
<qyliss> don't suppose you know where dynamic linker paths come from?
<qyliss> I see why it's not working now, but I'm still stumped
<sterni> isn't it an attribute of binutils in the bootstrap at some point?
<qyliss> I just discovered that :)
<sterni> I was quite amazed by this, but it is likely just the simplest place to plumb through the dynamic linker and libc
<qyliss> the dynamic linker doesn't come with libc on NetBSD (at least the way we currently have it set up)
<qyliss> Ericson2314: we have two options here -- put ld.elf_so in libc, or change that line to look at the ld_elf_so package
<qyliss> the latter feels cleaner, but then how do we actually find that package in the bintools wrapper? Is it okay to just take it as an input?
<sterni> Ericson2314: btw on compiler-rt: Do you want to continue passing "-DCOMPILER_RT_OS_DIR=" or do you want to revert that change?
<sterni> in the former case seems like we need to teach clang to not use the linux sub dir
<sterni> keeping the default os dir for compiler-rt makes useLLVM work again fwiw
<Ericson2314> qyliss: i think the binutils only takes `libc` for the dynamic linker? so we might as well change up that attribute a bit
<Ericson2314> that it was coming from libc was just an implementation detail
<Ericson2314> sterni: yet let's get rid of that
<Ericson2314> but we will need to symlink some stuff like before
<Ericson2314> let me fix that
<qyliss> Ericson2314: looks like it's used for other stuff too -- it looks at libc_bin
<sterni> Ericson2314: okay, at a quick glance that seemed to require less work
<sterni> since there was no immediate way to tell clang about it I could see
<Ericson2314> sterni: made you https://github.com/NixOS/nixpkgs/pull/122399
<Ericson2314> qyliss: oh huh
<Ericson2314> I'll go look and refresh my memory
<qyliss> Ericson2314: actually it looks like we'll have to build ld.elf_so in libc anyway
<sterni> Ericson2314: <3
<qyliss> wait no
<qyliss> ignore me
<Ericson2314> qyliss: I think removing `libc_bin` from bintools-wrapper altogether would be fine
<Ericson2314> I was very cautious when I split cc-wrapper and bintools-wrapper appart
<Ericson2314> arguably it might even be safe to do that for 21.05 because the vast majority of packages get both
<qyliss> Ericson2314: do you want to put a PR together with your proposed bintools wrapper change, using netbsd.ld_elf_so as the dynamic linker on NetBSD, then?
<qyliss> (Doesn't matter if it works on NetBSD -- I can fix that up)
<Ericson2314> qyliss: maybe but i am on a call with family for next hour or so
<qyliss> Ericson2314: that's fine, I'm going to bed
<Ericson2314> ok, goodnight!
<qyliss> night!
<qyliss> I think once this is done we should be ready for a pure native bootstrap
<Ericson2314> oh wow!
<qyliss> there'll be some build fixes, obviously
<qyliss> but this is the only major blocker that I currently know of