Nixpkgs: GCC cannot print its configuration options

[DavidEGrayson]

Issue description

It seems like any version of GCC 5.4.0 compiled by Nix cannot print its own configuration options when you run it with the -v option. Usually GCC prints a line that says "Configured with:" followed by the arguments that were passed to its configure script.

Steps to reproduce

Run nix-shell -p hello and then run gcc -v. It just says "Configured with:" and has no configuration options on that line.

Workaround

I suppose I can just look at the derivation files for the GCC in question to see how it was configured/built.

Technical details

• System: Arch Linux x86_64
• Nix version: nix-env (Nix) 1.11.2
• Nixpkgs version: 16.09pre88195.26d2577

[shlevy]

I think the reason for this is that otherwise gcc would keep a reference to all of its build-time dependencies, since those are hard-coded in the configure string, even if it didn't otherwise need them at runtime.

[Ericson2314]

Could we mangle the hash, e.g., insert underscores, as a hack around this?

[vcunat]

Probably possible, but I'm not sure it would be worth it.

[Ericson2314]

If I have some time I'll take a look at whatever patch removes the ability right now. If one can just sed a built-time log file, should be easy enough. If one needs to patch some C in GCC probably not worth it.

[DavidEGrayson]

I think mangling the hashes would just require one line that calls sed inside of the top-level configure file and modifies the variable TOPLEVEL_CONFIGURE_ARGUMENTS,

Does anyone know in particular what build-time dependencies GCC has which are listed in the configuration arguments and are not run-time dependencies? If those dependencies are small then maybe we should just have the full configure flags be printed and not try to mangle anything.

[vcunat]

If those dependencies are small

They are significant. It depends on the tools that bootstrap it, for example.

[Ericson2314]

_Transitively_ bootstrap, I might clarify. If it's just a sed it's definitely worth it.

[DavidEGrayson]

Are you sure that all the bootstrap tools are listed in the arguments to configure? The transitive ones would certainly not be there, and the direct ones might simply be detected using the PATH.

[vcunat]

Right, that might be true. I don't remember what exactly we pass among the flags.

[Ericson2314]

Er yeah, I meant runtime deps are transitively part of the closure, not transitively listed. And good point about $PATH.

[copumpkin]

We already have a nukeReferences tool that does the magic sed invocation for us, if that helps.

[Profpatsch]

(triage) has this been fixed?

[tomberek]

(triage) Not fixed, but we should consider closing due to age

[copumpkin]

Why is "closing due to age" a thing? If things are still desirable, I don't see why keeping information about a given desired feature/bug in a canonical discoverable location is a bad thing. Closing it just makes it harder for new folks to find out previous knowledge about the issue.

[tomberek]

Not a big deal. Perhaps add a label for backlog? I’m just trying to go through old issues and PR’s to clean them up right now. Having thousands of open issues can be intimidating, Perhaps mark as low priority?

[stale[bot]]

Thank you for your contributions.

This has been automatically marked as stale because it has had no activity for 180 days.

If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity.

Here are suggestions that might help resolve this more quickly:

1. Search for maintainers and people that previously touched the related code and @ mention them in a comment.
2. Ask on the NixOS Discourse.
3. Ask on the #nixos channel on irc.freenode.net.

[Profpatsch]

Anything to move this forward?