taffybar-1.0.2: gcc command line is too long because of repeated flags #40013
Comments
|
I assume this is on macOS or BSD? ARG_MAX is ridiculously high on Linux so I definitely hope we aren't hitting it there. Anyway, we can probably get rid of duplicate flags in cc-wrapper.sh - but the root problem is probably something else. Probably we are duplicating LDFLAGS somewhere. |
|
Nope, this is NixOS. There's a lot of duplication. |
|
/cc @peti |
|
that hack down for back-compat in 469fd89 is known to be a problem for haskell derivations. If the problematic flags go something like "... a b c d... a b c d... ..." (i.e. some long thing repeated twice) it's probably that. |
|
One thing we can do before reverting 469fd89 (which will involve fixing tons of) derivations is teach the wrapper scripts to put things back into response files if they get too long. This would be the opposite of |
|
+1 am running into this as well on a private project. |
|
#40186 is related too. |
|
@Ericson2314 looks like that's merged. Are we good to set |
|
Using |
|
Awesome! can you open pr? |
|
@Ericson2314 you said we should set |
|
I tried setting self: super: {
haskellPackages = super.haskellPackages.extend (hpSelf: hpSuper:
{
taffybar = hpSuper.taffybar.overrideDerivation (drv: { strictDeps = true; });(also with a fix for gi-dbusmenugtk3 in there) But I still get the same argument list too long error. (This is now taffybar-2.1, not 1.0.2 as in the original report) |
|
@cumber weird, I don't get that error. I'm running Taffybar 2.1 right now. |
|
@cumber I don't think that strictDeps has made it in to unstable yet (The argument would still be called crossConfig there) |
|
@puffnfresh is running off of master IIRC. |
|
@IvanMalison Ah thanks! That explains it. Setting |
|
@cumber What error do you get? |
|
I think that it might actually be best to fix this in cabal itself: The relevant code is here: Basically I think that we need to do some deduplication there, perhaps simply by changing the type of the object in question to Set from list. |
|
Looks like @nh2 beat me to the punch #41340 is a more general version of this issue |
|
After some more investigation, I've discovered that the main reason this is hitting taffybar so badly has to do with the fact that it has an hsc file. The hsc file is actually handled by a separate binary hsc2hs, which does no deduplication of the include flags at all. It is now possible to build taffybar using stack in nix. I haven't looked in to building it the proper nix way, but I suspect that the issue might be gone now as well. Worth some investigation. |
|
@IvanMalison I have just tried the latest master version from |
|
Can someone enlighten me what Which stops haskell packages from generating |
|
A change has made it in to taffybar such that we no longer call in to hsc2hs in 2.1.2. Can any of you verify that this fixes the issue you mentioned here? |
|
I imagine @peti will pick up 2.1.2 in the next day or so, in which case I'll check the build. 2.1.1 is working for me with |
Issue description
If I attempt to build the
taffybar-1.0.2package, it fails with gcc complaining about a too-long command-line:If you actually analyze the command-line, though, there are endlessly repeated copies of -L and -Wl flags, all pointing to the exact same paths. For instance:
so it seems like something somewhere has gone wrong...
Steps to reproduce
nix-build --attr haskellPackages.taffybar
First, though, you need to fix two other packages,
haskell-giandgi-gdkx11.Technical details
Please run
nix-shell -p nix-info --run "nix-info -m"and paste theresults.
The text was updated successfully, but these errors were encountered: