How about moving them to a separate output, such as bin? Then they'll still be available if needed but will typically be excluded from dependers' closures.

I don't think musl-gcc and the like are spurious junk we can just get rid of.
If you want pure musl packages, use pkgsMusl instead.

Fixes #75476 for me

@symphorien can you show how you'd get a pure musl package without glibc given the sample project in #75476 without this change?

@r-burns possibly a decent solution, I'll see if I can't split it off. Ideally though the musl scripts would use a bash built against musl, but that seems impossible without moving the scripts to their own derivation? I'm still new-ish to writing nix but hard to see how it'd be possible otherwise.

@symphorien can you show how you'd get a pure musl package without glibc given the sample project in #75476 without this change?

let
  musl = (import <nixpkgs/lib>).systems.examples.musl64;
  musl-pkgs = (import <nixpkgs> {}).pkgsMusl;

  host-pkgs = import <nixpkgs> {};

  build = pkgs:
    let
      inherit (pkgs) stdenv;
    in
    stdenv.mkDerivation {
      name = "hello";
      src = ./.;

      buildPhase = ''
        $CXX hello.cc
      '';

      installPhase = ''
        mkdir -p $out/bin
        cp a.out $out/bin
      '';
    };
in
  {
    host = build host-pkgs;
    musl = build musl-pkgs;
  }

$  nix-build -A musl
these derivations will be built:
  /nix/store/3jkmx2gz2ps8q7hf2y1svxfy3jvn0ms9-hello.drv
building '/nix/store/3jkmx2gz2ps8q7hf2y1svxfy3jvn0ms9-hello.drv'...
unpacking sources
unpacking source archive /nix/store/6wqpdbiyk98q0s8ipgmdv286515d7v97-foo
source root is foo
patching sources
updateAutotoolsGnuConfigScriptsPhase
configuring
no configure script, doing nothing
building
installing
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/bnd7srs7x7h81574q5drnsvnmqrf5yxb-hello
shrinking /nix/store/bnd7srs7x7h81574q5drnsvnmqrf5yxb-hello/bin/a.out
strip is /nix/store/cdbsfljc8m900axs37fab7gnp2y1dksn-binutils-2.31.1/bin/strip
stripping (with command strip and flags -S) in /nix/store/bnd7srs7x7h81574q5drnsvnmqrf5yxb-hello/bin
patching script interpreter paths in /nix/store/bnd7srs7x7h81574q5drnsvnmqrf5yxb-hello
checking for references to /build/ in /nix/store/bnd7srs7x7h81574q5drnsvnmqrf5yxb-hello...
/nix/store/bnd7srs7x7h81574q5drnsvnmqrf5yxb-hello
                                                                                                                                                                                              

$  nix-store -qR result
/nix/store/dl4gwchzfl6gxaf8xgvrva29k9m2zk77-musl-1.2.0
/nix/store/78iyhz8ci6vdqzybf1bl9kbs45w2bv94-gcc-9.3.0-lib
/nix/store/bnd7srs7x7h81574q5drnsvnmqrf5yxb-hello

As I said, if you want a pure musl artifact, the most direct solution is to use a pure musl toolchain, that is pkgsMusl.

Anyway, I think removing musl-gcc is a regression and thus not an acceptable solution.

@symphorien fair enough, I didn't like it either to be quite honest, but was confused entirely by the musl -> bash -> glibc dep chain going on, which seems... wrong. Even if you do depend on the musl-dev shouldn't that avoid relying on glibc as it may inherently blow up closure size in some cases where the -dev related stuff is needed still?

My ultimate goal with this work is to be able to cross compile, with musl, to multiple target archs as well so I'm not sure if that changes the outcome here

If you insist on cross compiling and not having glibc in the build-platform compiler, then you should cross compile from a musl build platform. Untested, but pkgsMusl.pkgsCross might do that.

I do think -dev shouldn't depend on bash and glibc by default, but I agree with comments that removing the scripts isn't the right path. Closing