Change:
, groff, docSupport ? true , libyaml, yamlSupport ? true , libffi, fiddleSupport ? true <del> # ruby -e "puts RbConfig::CONFIG['configure_args']" # puts a reference to the C compiler in the binary. # This might be required by some gems at runtime, # but we allow to strip it out for smaller closure size. , removeReferencesTo, removeReferenceToCC ? true </del> <ins> # By default, ruby has 3 observed references to stdenv.cc: # # - If you run: #     ruby -e "puts RbConfig::CONFIG['configure_args']" # - In: #     $out/${passthru.libPath}/${stdenv.targetPlatform.system}/rbconfig.rb #   Or (usually): #     $(nix-build -A ruby)/lib/ruby/2.6.0/x86_64-linux/rbconfig.rb # - In $out/lib/libruby.so and/or $out/lib/libruby.dylib # # Since some Gems require JIT support, there's probably no # escape from this reference. Hence, it was decided to enable this # feature by default, as it's enabled by default by ruby's ./configure # script. If you'd like to have a ruby without reference to cc, setting # jitSupport to false should remove all known references mentioned above. , removeReferencesTo, jitSupport ? true </ins> , autoreconfHook, bison, autoconf , buildEnv, bundler, bundix , libiconv, libobjc, libunwind, Foundation

Discussion:
Describe the bug I'm hunting down packages that reference gcc. One of them is (maintainers: & ). Here's why: The fault is the fact that the build flag doesn't remove all references, as one might expect (EDIT, see: ). I'm up to including this feature, but I was wondering perhaps it'd be legit to disable this feature for the derivation? I opened a PR at (EDIT).
But that would mean gems that require a compiler would no longer work.
The suggestion is for , not . Isn't the derivation that's used to build the gems? According to:
It still has support for gems, so some will fail with gcc. What exactly is the use case for ?
Technically it's not used anywhere, according to .
I'd like to make my - with an overlay. The goal is to make the 1 or 2 pure ruby scripts I have on my system not pull , as they do today.
But what is the reason? You're likely to have a version of ruby that includes gcc on your system anyway, so you don't really save any space. And the use-case would be plain ruby scripts with only the gems that don't require system libraries. We have no users in nixpkgs of presumably because it's rather pointless. And while of course we can strip gcc from rubyMinimal (there's no harm), I'd rather say drop instead.
Not If I'll apply and this overlay: This allows me to not need GCC for for example - which is the only ruby gem I use. For example, run with this PR and that overlay applied: And you should get: And without , (and without the overlay because it would fail) you should get: is the only derivation that needs ruby that I actually use. I've updated the 1st comment in to exemplify this overlay as a possible usecase. Well I tend to agree - even for asciidoctor which should be pretty much a pure ruby gem, it still required and which aren't enabled in current . Hence I tend to agree. OK so I've updated to include a drop to , including release notes and an alias. Waiting for your review :crossed_fingers: .
This issue has been mentioned on NixOS Discourse. There might be relevant details there: