Change:
Alacritty has the wrong RPATH. It does not include glibc or libgcc, which causes it to use the system's libraries on non-nixos systems. This is likely because the derivation for Alacritty sets RPATH manually, and does not include these libraries (probably just an oversight, since these are normally taken care of by ). Notice that , and all end up using system libraries. This is because the runpath is wrong: Alacritty should link to the libc in the nix store at runtime.
AFAIU does not have to be in : those paths are already present in specified in in section. I suspect you are using from the host system and thus use it's interpreter, not 's. Try from . More direct way to se what loads what is to run it via . I suspect you are loading wrong via drivers.
I think I've seen something like that with , but I haven't bother sending a fix upstream. What happens is that manual setting purges everything, so if you cross build it simply doesn't work the way alacritty's derivation is doing so. What I was doing instead, is appending for runtime deps in phase and enable default running. That's an example of what I do for other package using the exact same dependencies as alacritty. Which makes it start when to other target.
I think the correct way to override default search paths of is via environment variables like . But / intentionally does not embed those into binaries to allow mesa or vendor drivers to be pluged in without the rebuild of the all client apps.
is a related issue in nixpkgs-architecture component.
The in removes all default searching and break. Using variables is not really a solution to it, given that is not the only thing by alacritty, it also and . Similar thing is done by other windowing libs, like and .
I think derivation already passes and to : . My suggestion to use variables (as a workaround on non-NixOS) was only for mesa drivers. should still embed needed s to make the rest of libraries work. Initial report claims and are loaded from the wrong location. I don't believe it's true.
But I think it's sort of expected given that you , so you load from whatever you can find? I might be not experienced here, but if you alacritty for to , it won't ever find a , and similar. The only way to make it find is to allow and then, on a phase, do With all the libs alacritty wants. Be aware, it's , not , I don't even understand what is the motivation for , other derivation like (similar situation), are stuff, not . Initial report claims libc and libm are loaded from the wrong location. I don't believe it's true. Could you alacritty in your setup? I think that should be enough to verify that, ?
Running it under might be enough as well.
I encountered this too, and cheated with . I am working on a fix.
I do something like that in my overlay, works in my cases with cross , setting will prune the old one according to , and I haven't seen much projects doing so, most use .
Yeah, I agree looks fishy.
Unfortunately there are serious problems with the in cross-compiled builds right now: Fortunately there is a Now that that is taken care of I will work on this issue next. I think you have the right strategy with this idea: ... that is the first thing I will try.

Discussion:
# As a workaround, strip manually before running patchelf. $STRIP -S $out/bin/alacritty <del> patchelf --set-rpath "${lib.makeLibraryPath rpathLibs}" $out/bin/alacritty </del> <ins> patchelf --add-rpath "${lib.makeLibraryPath rpathLibs}" $out/bin/alacritty </ins> '' ) + ''