Change:
Describe the bug While compiling gcc7 (or gcc8) in a non-sandboxed darwin enironment (as a Linux user I'm still trying to wrap my head around the sandboxing on darwin), I get compilation failures. To Reproduce To reproduce this exactly like I did, is probably nonsense, since it will cause almost every package to recompile. Essentially this came after modification to libdispatch, where I the following command at the end of the installPhase (I add here to rule out that these two may be connected). Alternatively dummy modify and build on commit or later. Metadata ADDED: I can confirm that this bug has nothing to do with the change I did on libdispatch, since I reverted it and rebuilt, getting the same error.
I got same issue Version: 0.51.2 Source dir: /build/fribidi-1.0.7 Build dir: /build/fribidi-1.0.7/build Build type: native build DEPRECATION: Duplicated values in array option is deprecated. This will become a hard error in the future. DEPRECATION: Duplicated values in array option is deprecated. This will become a hard error in the future. DEPRECATION: Duplicated values in array option is deprecated. This will become a hard error in the future. Project name: fribidi Project version: 1.0.7 ERROR: Unknown compiler(s): [['/nix/store/38rh09iclvs97fisbgy8fg6wxr33ijr1-gcc-wrapper-8.3.0/bin/cc']] Metadata
I get the same issue on NixOS. I don't believe this is Darwin-specific.
Several of us on irc are seeing this issue as well, across diverse packages. edit: I can confirm that does not have this issue maybe change the issue title to reflect that this Unknown compiler issue is broader than just libstdc++ & darwin?
It has been fixed by
Sorry late to the party. Will test and close, unless it's still broken then I'll change the title.
Tested few times again, rebases and darwin system update, and this is still there. We must have been referring to a different bug. I'm clueless about why I encounter this. I'm not a heavy darwin user and I haven't done much to my MacBook Pro. I may add these warning that appear, if they mean anything
Hi from the distant future, 3 months later. I am experiencing this exact problem. GCC 9 and GFortran 9 also fail to compile with a similar error about . (Background: I have Nix installed to the nonstandard location to work around NixOS/nix, so I have to compile everything from scratch.) I've done some digging and I think I have a lead on what's causing this (but no solution yet). Having seen what's wrong, it's actually surprising to me that GCC builds on any Darwin computer. We really need to figure out why our systems are different from the Nix build farm. Here are the relevant snippets, in order from "easiest to obtain" to "hardest to obtain". GCC 9 failure when compiling libgomp: With GCC 8 I get the same build failure in the original issue description, which is worded differently but is essentially the same. One of the many messages printed when configuring libgomp: Aha, now that's suspicious. The header in actually doesn't have ! How did the configure script find it? Here's a look at libgomp's file: So, here's my hypothesis: GCC recognizes as a builtin procedure and handles it specially. The bootstrap compiler uses GCC's special handling for but also uses the standard library in . During configuration, converts what should be an error about missing to a warning about how it has been implicitly declared. During compilation, properly throws an error about missing .
New hypothesis: this issue is specific to MacOS 10.15 (Catalina). The 10.15 system libraries include while the 10.14 and earlier libraries do not: Ultimately, I think the problem is a disagreement between the version 10.12 headers that Nix uses and the actual binary API offered by the system libraries. GCC fails to build because is linkable but not present in the headers.
I marked this as stale due to inactivity. &rarr;
Fixed by

Discussion:
'' + lib.optionalString (lib.versionOlder version "7" && (langJava || langGo)) '' export lib=$out; '' <ins> # NOTE 2020/3/18: This environment variable prevents configure scripts from # detecting the presence of aligned_alloc on Darwin.  There are many facts that # collectively make this fix necessary: #  - Nix uses a fixed set of standard library headers on all MacOS systems, #    regardless of their actual version.  (Nix uses version 10.12 headers.) #  - Nix uses the native standard library binaries for the build system.  That #    means the standard library binaries may not exactly match the standard #    library headers. #  - The aligned_alloc procedure is present in MacOS 10.15 (Catalina), but not #    in earlier versions.  Therefore on Catalina systems, aligned_alloc is #    linkable (i.e. present in the binary libraries) but not present in the #    headers. #  - Configure scripts detect a procedure's existence by checking whether it is #    linkable.  They do not check whether it is present in the headers. #  - GCC throws an error during compilation because aligned_alloc is not #    defined in the headers---even though the linker can see it. # # This fix would not be necessary if ANY of the above were false: #  - If Nix used native headers for each different MacOS version, aligned_alloc #    would be in the headers on Catalina. #  - If Nix used the same libary binaries for each MacOS version, aligned_alloc #    would not be in the library binaries. #  - If Catalina did not include aligned_alloc, this wouldn't be a problem. #  - If the configure scripts looked for header presence as well as #    linkability, they would see that aligned_alloc is missing. #  - If GCC allowed implicit declaration of symbols, it would not fail during #    compilation even if the configure scripts did not check header presence. # + lib.optionalString (hostPlatform.isDarwin) '' export ac_cv_func_aligned_alloc=no '' </ins>