Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

gcc7 libstdc++ on darwin fails to compile #73319

Closed
hlolli opened this issue Nov 13, 2019 · 10 comments · Fixed by #82921
Closed

gcc7 libstdc++ on darwin fails to compile #73319

hlolli opened this issue Nov 13, 2019 · 10 comments · Fixed by #82921
Labels
0.kind: bug 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md 6.topic: darwin Running or building packages on Darwin

Comments

@hlolli
Copy link
Member

hlolli commented Nov 13, 2019 •
edited

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.

/nix/store/z4rsz8dl3s9qlvbvs9wbfk5ahwfhqrli-bash-4.4-p23/bin/bash ../libtool --tag CXX --tag disable-shared   --mode=compile /private/var/folders/9k/hr12t49132lgnpzq88w_h6740000gn/T/nix-build-gcc-8.3.0.drv-0/build/./gcc/xgcc -shared-libgcc -B/private/var/folders/9k/hr12t49132lgnpzq88w_h6740000gn/T/nix-build-gcc-8.3.0.drv-0/build/./gcc -nostdinc++ -L/private/var/folders/9k/hr12t49132lgnpzq88w_h6740000gn/T/nix-build-gcc-8.3.0.drv-0/build/x86_64-apple-darwin/libstdc++-v3/src -L/private/var/folders/9k/hr12t49132lgnpzq88w_h6740000gn/T/nix-build-gcc-8.3.0.drv-0/build/x86_64-apple-darwin/libstdc++-v3/src/.libs -L/private/var/folders/9k/hr12t49132lgnpzq88w_h6740000gn/T/nix-build-gcc-8.3.0.drv-0/build/x86_64-apple-darwin/libstdc++-v3/libsupc++/.libs -O2 -I/nix/store/b0wshq9a0b7x9kvw8ca0bhljgjp3vgyl-Libsystem-osx-10.12.6/include -B/nix/store/b0wshq9a0b7x9kvw8ca0bhljgjp3vgyl-Libsystem-osx-10.12.6/lib/ -idirafter /nix/store/b0wshq9a0b7x9kvw8ca0bhljgjp3vgyl-Libsystem-osx-10.12.6/include -Wl,-rpath,/nix/store/bgpnnbyxjkipldxhiwyx9pd7pysf6qzj-gcc-8.3.0-lib/lib -Wl,-L/nix/store/b0wshq9a0b7x9kvw8ca0bhljgjp3vgyl-Libsystem-osx-10.12.6/lib -Wl,-rpath -Wl,/nix/store/b0wshq9a0b7x9kvw8ca0bhljgjp3vgyl-Libsystem-osx-10.12.6/lib -Wl,-L/nix/store/b0wshq9a0b7x9kvw8ca0bhljgjp3vgyl-Libsystem-osx-10.12.6/lib    -I/private/var/folders/9k/hr12t49132lgnpzq88w_h6740000gn/T/nix-build-gcc-8.3.0.drv-0/gcc-8.3.0/libstdc++-v3/../libgcc -I/private/var/folders/9k/hr12t49132lgnpzq88w_h6740000gn/T/nix-build-gcc-8.3.0.drv-0/build/x86_64-apple-darwin/libstdc++-v3/include/x86_64-apple-darwin -I/private/var/folders/9k/hr12t49132lgnpzq88w_h6740000gn/T/nix-build-gcc-8.3.0.drv-0/build/x86_64-apple-darwin/libstdc++-v3/include -I/private/var/folders/9k/hr12t49132lgnpzq88w_h6740000gn/T/nix-build-gcc-8.3.0.drv-0/gcc-8.3.0/libstdc++-v3/libsupc++   -prefer-pic -D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi  -fdiagnostics-show-location=once    -ffunction-sections -fdata-sections  -frandom-seed=del_opant.lo -O2 -I/nix/store/b0wshq9a0b7x9kvw8ca0bhljgjp3vgyl-Libsystem-osx-10.12.6/include -B/nix/store/b0wshq9a0b7x9kvw8ca0bhljgjp3vgyl-Libsystem-osx-10.12.6/lib/ -idirafter /nix/store/b0wshq9a0b7x9kvw8ca0bhljgjp3vgyl-Libsystem-osx-10.12.6/include -Wl,-rpath,/nix/store/bgpnnbyxjkipldxhiwyx9pd7pysf6qzj-gcc-8.3.0-lib/lib -Wl,-L/nix/store/b0wshq9a0b7x9kvw8ca0bhljgjp3vgyl-Libsystem-osx-10.12.6/lib -Wl,-rpath -Wl,/nix/store/b0wshq9a0b7x9kvw8ca0bhljgjp3vgyl-Libsystem-osx-10.12.6/lib -Wl,-L/nix/store/b0wshq9a0b7x9kvw8ca0bhljgjp3vgyl-Libsystem-osx-10.12.6/lib  -std=gnu++1z -c ../../../../gcc-8.3.0/libstdc++-v3/libsupc++/del_opant.cc
In file included from /private/var/folders/9k/hr12t49132lgnpzq88w_h6740000gn/T/nix-build-gcc-8.3.0.drv-0/build/x86_64-apple-darwin/libstdc++-v3/include/stdlib.h:36,
                 from ../../../../gcc-8.3.0/libstdc++-v3/libsupc++/new_opa.cc:27:
/private/var/folders/9k/hr12t49132lgnpzq88w_h6740000gn/T/nix-build-gcc-8.3.0.drv-0/build/x86_64-apple-darwin/libstdc++-v3/include/cstdlib:132:11: error: '::aligned_alloc' has not been declared
   using ::aligned_alloc;
           ^~~~~~~~~~~~~

/nix/store/z4rsz8dl3s9qlvbvs9wbfk5ahwfhqrli-bash-4.4-p23/bin/bash ../libtool --tag CXX --tag disable-shared   --mode=compile /private/var/folders/9k/hr12t49132lgnpzq88w_h6740000gn/T/nix-build-gcc-8.3.0.drv-0/build/./gcc/xgcc -shared-libgcc -B/private/var/folders/9k/hr12t49132lgnpzq88w_h6740000gn/T/nix-build-gcc-8.3.0.drv-0/build/./gcc -nostdinc++ -L/private/var/folders/9k/hr12t49132lgnpzq88w_h6740000gn/T/nix-build-gcc-8.3.0.drv-0/build/x86_64-apple-darwin/libstdc++-v3/src -L/private/var/folders/9k/hr12t49132lgnpzq88w_h6740000gn/T/nix-build-gcc-8.3.0.drv-0/build/x86_64-apple-darwin/libstdc++-v3/src/.libs -L/private/var/folders/9k/hr12t49132lgnpzq88w_h6740000gn/T/nix-build-gcc-8.3.0.drv-0/build/x86_64-apple-darwin/libstdc++-v3/libsupc++/.libs -O2 -I/nix/store/b0wshq9a0b7x9kvw8ca0bhljgjp3vgyl-Libsystem-osx-10.12.6/include -B/nix/store/b0wshq9a0b7x9kvw8ca0bhljgjp3vgyl-Libsystem-osx-10.12.6/lib/ -idirafter /nix/store/b0wshq9a0b7x9kvw8ca0bhljgjp3vgyl-Libsystem-osx-10.12.6/include -Wl,-rpath,/nix/store/bgpnnbyxjkipldxhiwyx9pd7pysf6qzj-gcc-8.3.0-lib/lib -Wl,-L/nix/store/b0wshq9a0b7x9kvw8ca0bhljgjp3vgyl-Libsystem-osx-10.12.6/lib -Wl,-rpath -Wl,/nix/store/b0wshq9a0b7x9kvw8ca0bhljgjp3vgyl-Libsystem-osx-10.12.6/lib -Wl,-L/nix/store/b0wshq9a0b7x9kvw8ca0bhljgjp3vgyl-Libsystem-osx-10.12.6/lib    -I/private/var/folders/9k/hr12t49132lgnpzq88w_h6740000gn/T/nix-build-gcc-8.3.0.drv-0/gcc-8.3.0/libstdc++-v3/../libgcc -I/private/var/folders/9k/hr12t49132lgnpzq88w_h6740000gn/T/nix-build-gcc-8.3.0.drv-0/build/x86_64-apple-darwin/libstdc++-v3/include/x86_64-apple-darwin -I/private/var/folders/9k/hr12t49132lgnpzq88w_h6740000gn/T/nix-build-gcc-8.3.0.drv-0/build/x86_64-apple-darwin/libstdc++-v3/include -I/private/var/folders/9k/hr12t49132lgnpzq88w_h6740000gn/T/nix-build-gcc-8.3.0.drv-0/gcc-8.3.0/libstdc++-v3/libsupc++   -prefer-pic -D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi  -fdiagnostics-show-location=once    -ffunction-sections -fdata-sections  -frandom-seed=del_opva.lo -O2 -I/nix/store/b0wshq9a0b7x9kvw8ca0bhljgjp3vgyl-Libsystem-osx-10.12.6/include -B/nix/store/b0wshq9a0b7x9kvw8ca0bhljgjp3vgyl-Libsystem-osx-10.12.6/lib/ -idirafter /nix/store/b0wshq9a0b7x9kvw8ca0bhljgjp3vgyl-Libsystem-osx-10.12.6/include -Wl,-rpath,/nix/store/bgpnnbyxjkipldxhiwyx9pd7pysf6qzj-gcc-8.3.0-lib/lib -Wl,-L/nix/store/b0wshq9a0b7x9kvw8ca0bhljgjp3vgyl-Libsystem-osx-10.12.6/lib -Wl,-rpath -Wl,/nix/store/b0wshq9a0b7x9kvw8ca0bhljgjp3vgyl-Libsystem-osx-10.12.6/lib -Wl,-L/nix/store/b0wshq9a0b7x9kvw8ca0bhljgjp3vgyl-Libsystem-osx-10.12.6/lib  -std=gnu++1z -c ../../../../gcc-8.3.0/libstdc++-v3/libsupc++/del_opva.cc
../../../../gcc-8.3.0/libstdc++-v3/libsupc++/new_opa.cc:47:9: error: '::aligned_alloc' has not been declared
 using ::aligned_alloc;
         ^~~~~~~~~~~~~
../../../../gcc-8.3.0/libstdc++-v3/libsupc++/new_opa.cc: In function 'void* operator new(std::size_t, std::align_val_t)':
../../../../gcc-8.3.0/libstdc++-v3/libsupc++/new_opa.cc:128:20: error: '__gnu_cxx::aligned_alloc' has not been declared
   using __gnu_cxx::aligned_alloc;
                    ^~~~~~~~~~~~~
../../../../gcc-8.3.0/libstdc++-v3/libsupc++/new_opa.cc:129:33: error: 'aligned_alloc' was not declared in this scope
   while (__builtin_expect ((p = aligned_alloc (align, sz)) == 0, false))
                                 ^~~~~~~~~~~~~

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 added the following command at the end of the installPhase (I add here to rule out that these two may be connected).

# gcc compatability. Source: https://stackoverflow.com/a/28014302/3714556
    substituteInPlace $out/include/dispatch/object.h \
      --replace 'typedef void (^dispatch_block_t)(void);' \
                '#ifdef __clang__
                 typedef void (^dispatch_block_t)(void);
                 #else
                 typedef void* dispatch_block_t;
                 #endif'

Alternatively dummy modify nixpkgs/pkgs/development/compilers/gcc/7/default.nix and build nix-build . -A gcc7 on commit 6236cffa69757549207ad7d2001d96ac16ad1cdf or later.

Metadata

 - system: `"x86_64-darwin"`
 - host os: `Darwin 19.0.0, macOS 10.15`
 - multi-user?: `no`
 - sandbox: `no`
 - version: `nix-env (Nix) 2.3.1`
 - channels(root): `"nixpkgs-20.03pre196811.7818f30cc4b"`
 - channels(hlolli): `"darwin, nixpkgs-20.03pre196811.7818f30cc4b"`
 - nixpkgs: `/Users/hlolli/.nix-defexpr/channels/nixpkgs`

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.
@GTrunSec
Copy link
Contributor

GTrunSec commented Nov 13, 2019 •
edited

I got same issue

The Meson build system
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
meson.build:1:0: ERROR: Unknown compiler(s): [['/nix/store/38rh09iclvs97fisbgy8fg6wxr33ijr1-gcc-wrapper-8.3.0/bin/cc']]

Metadata

 - system: `"x86_64-linux"`
 - host os: `Linux 4.19.81, NixOS, 20.03.git.eddc487 (Markhor)`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.3.1`
 - channels(root): `"nixos-20.03pre197685.f35f0880f2c, nixos-unstable-19.09pre190687.3f4144c30a6"`
 - channels(gtrun): `"home-manager, nixos-20.03pre200231.7827d3f4497, unstable-20.03pre201329.f1682a7f126"`
 - nixpkgs: `/etc/nixos/channel/nixpkgs`

@Slabity
Copy link
Contributor

Slabity commented Nov 13, 2019

I get the same issue on NixOS. I don't believe this is Darwin-specific.

@tbenst
Copy link
Contributor

tbenst commented Nov 14, 2019 •
edited

Several of us on irc are seeing this issue as well, across diverse packages.

unpacking source archive /nix/store/s2fbsgci9j4rf1fjz9dvna9fmjj55p04-recode-3.7.6.tar.gz
source root is xorgproto-2019.1
setting SOURCE_DATE_EPOCH to timestamp 1561000386 of file xorgproto-2019.1/specs/xproto/Makefile.in
patching sources
configuring
meson flags: --buildtype=plain         --libdir=/nix/store/41yzass51vf1hg33q0s75sjlyzsm02p9-xorgproto-2019.1/lib --libexecdir=/nix/store/41yzass51vf1hg33q0s75sjlyzsm02p9-xorgproto-2019.1/libexec         --bindir=/nix/store/41yzass51vf1hg33q0s75sjlyzsm02p9-xorgproto-2019.1/bin --sbindir=/nix/store/41yzass51vf1hg33q0s75sjlyzsm02p9-xorgproto-2019.1/sbin         --includedir=/nix/store/41yzass51vf1hg33q0s75sjlyzsm02p9-xorgproto-2019.1/include         --mandir=/nix/store/41yzass51vf1hg33q0s75sjlyzsm02p9-xorgproto-2019.1/share/man --infodir=/nix/store/41yzass51vf1hg33q0s75sjlyzsm02p9-xorgproto-2019.1/share/info         --localedir=/nix/store/41yzass51vf1hg33q0s75sjlyzsm02p9-xorgproto-2019.1/share/locale         -Dauto_features=enabled         -Dwrap_mode=nodownload         --prefix=/nix/store/41yzass51vf1hg33q0s75sjlyzsm02p9-xorgproto-2019.1 -Dlegacy=true
source root is recode-3.7.6
setting SOURCE_DATE_EPOCH to timestamp 1568377737 of file recode-3.7.6/tests/Recode.c
patching sources
configuring
fixing libtool script ./build-aux/ltmain.sh
configure flags: --disable-static --disable-dependency-tracking --prefix=/nix/store/z3ra61zb6c9rfyh1r9hhraj1rf793qd9-recode-3.7.6
checking for a BSD-compatible install... /nix/store/gnw6yrqy249n62r4q8vy12ispviv3dav-coreutils-8.31/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /nix/store/gnw6yrqy249n62r4q8vy12ispviv3dav-coreutils-8.31/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
The Meson build system
Version: 0.51.2
Source dir: /build/xorgproto-2019.1
Build dir: /build/xorgproto-2019.1/build
Build type: native build
Project name: xorgproto
Project version: 2019.1

meson.build:21:0: ERROR: Unknown compiler(s): [['/nix/store/38rh09iclvs97fisbgy8fg6wxr33ijr1-gcc-wrapper-8.3.0/bin/cc']]

A full log can be found at /build/xorgproto-2019.1/build/meson-logs/meson-log.txt
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking for style of include used by make... GNU
checking for gcc... gcc
builder for '/nix/store/d6i093f12nlbyfnaclh4xwr9lnc395fk-xorgproto-2019.1.drv' failed with exit code 1

https://gist.github.com/tbenst/30758ffed0d3c7b1a03515dd6b84e318

edit: I can confirm that f5ddd10 does not have this issue
@hlolli maybe change the issue title to reflect that this Unknown compiler issue is broader than just libstdc++ & darwin?

@GTrunSec
Copy link
Contributor

GTrunSec commented Nov 15, 2019 •
edited

Several of us on irc are seeing this issue as well, across diverse packages.

unpacking source archive /nix/store/s2fbsgci9j4rf1fjz9dvna9fmjj55p04-recode-3.7.6.tar.gz
source root is xorgproto-2019.1
setting SOURCE_DATE_EPOCH to timestamp 1561000386 of file xorgproto-2019.1/specs/xproto/Makefile.in
patching sources
configuring
meson flags: --buildtype=plain         --libdir=/nix/store/41yzass51vf1hg33q0s75sjlyzsm02p9-xorgproto-2019.1/lib --libexecdir=/nix/store/41yzass51vf1hg33q0s75sjlyzsm02p9-xorgproto-2019.1/libexec         --bindir=/nix/store/41yzass51vf1hg33q0s75sjlyzsm02p9-xorgproto-2019.1/bin --sbindir=/nix/store/41yzass51vf1hg33q0s75sjlyzsm02p9-xorgproto-2019.1/sbin         --includedir=/nix/store/41yzass51vf1hg33q0s75sjlyzsm02p9-xorgproto-2019.1/include         --mandir=/nix/store/41yzass51vf1hg33q0s75sjlyzsm02p9-xorgproto-2019.1/share/man --infodir=/nix/store/41yzass51vf1hg33q0s75sjlyzsm02p9-xorgproto-2019.1/share/info         --localedir=/nix/store/41yzass51vf1hg33q0s75sjlyzsm02p9-xorgproto-2019.1/share/locale         -Dauto_features=enabled         -Dwrap_mode=nodownload         --prefix=/nix/store/41yzass51vf1hg33q0s75sjlyzsm02p9-xorgproto-2019.1 -Dlegacy=true
source root is recode-3.7.6
setting SOURCE_DATE_EPOCH to timestamp 1568377737 of file recode-3.7.6/tests/Recode.c
patching sources
configuring
fixing libtool script ./build-aux/ltmain.sh
configure flags: --disable-static --disable-dependency-tracking --prefix=/nix/store/z3ra61zb6c9rfyh1r9hhraj1rf793qd9-recode-3.7.6
checking for a BSD-compatible install... /nix/store/gnw6yrqy249n62r4q8vy12ispviv3dav-coreutils-8.31/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /nix/store/gnw6yrqy249n62r4q8vy12ispviv3dav-coreutils-8.31/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
The Meson build system
Version: 0.51.2
Source dir: /build/xorgproto-2019.1
Build dir: /build/xorgproto-2019.1/build
Build type: native build
Project name: xorgproto
Project version: 2019.1

meson.build:21:0: ERROR: Unknown compiler(s): [['/nix/store/38rh09iclvs97fisbgy8fg6wxr33ijr1-gcc-wrapper-8.3.0/bin/cc']]

A full log can be found at /build/xorgproto-2019.1/build/meson-logs/meson-log.txt
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking for style of include used by make... GNU
checking for gcc... gcc
builder for '/nix/store/d6i093f12nlbyfnaclh4xwr9lnc395fk-xorgproto-2019.1.drv' failed with exit code 1

https://gist.github.com/tbenst/30758ffed0d3c7b1a03515dd6b84e318

edit: I can confirm that f5ddd10 does not have this issue
@hlolli maybe change the issue title to reflect that this Unknown compiler issue is broader than just libstdc++ & darwin?

It has been fixed by #73423

@hlolli
Copy link
Member Author

hlolli commented Nov 15, 2019

Sorry late to the party. Will test and close, unless it's still broken then I'll change the title.

@hlolli
Copy link
Member Author

hlolli commented Nov 18, 2019 •
edited

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

cc1plus: warning: -Wabi won't warn about anything [-Wabi]
cc1plus: note: -Wabi warns about differences from the most up-to-date ABI, which is also used by default
cc1plus: note: use e.g. -Wabi=11 to warn about changes from GCC 7
cc1plus: warning: -Wabi won't warn about anything [-Wabi]
cc1plus: note: -Wabi warns about differences from the most up-to-date ABI, which is also used by default
cc1plus: note: use e.g. -Wabi=11 to warn about changes from GCC 7
cc1plus: warning: -Wabi won't warn about anything [-Wabi]
cc1plus: note: -Wabi warns about differences from the most up-to-date ABI, which is also used by default
cc1plus: note: use e.g. -Wabi=11 to warn about changes from GCC 7
cc1plus: warning: -Wabi won't warn about anything [-Wabi]
cc1plus: note: -Wabi warns about differences from the most up-to-date ABI, which is also used by default
cc1plus: note: use e.g. -Wabi=11 to warn about changes from GCC 7
cc1plus: warning: -Wabi won't warn about anything [-Wabi]
cc1plus: note: -Wabi warns about differences from the most up-to-date ABI, which is also used by default
cc1plus: note: use e.g. -Wabi=11 to warn about changes from GCC 7
cc1plus: warning: -Wabi won't warn about anything [-Wabi]
cc1plus: note: -Wabi warns about differences from the most up-to-date ABI, which is also used by default
cc1plus: note: use e.g. -Wabi=11 to warn about changes from GCC 7
cc1plus: warning: -Wabi won't warn about anything [-Wabi]
cc1plus: note: -Wabi warns about differences from the most up-to-date ABI, which is also used by default
cc1plus: note: use e.g. -Wabi=11 to warn about changes from GCC 7

@Calvin-L
Copy link
Contributor

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 aligned_alloc.

(Background: I have Nix installed to the nonstandard location /opt/nix to work around NixOS/nix#2925, 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:

libtool: compile:  /private/var/folders/d4/n6djsq8x5dv0jfx84hzl0v000000gn/T/nix-build-gfortran-9.2.0.drv-0/build/./gcc/xgcc -B/private/var/folders/d4/n6djsq8x5dv0jfx84hzl0v000000gn/T/nix-build-gfortran-9.2.0.drv-0/build/./gcc/ -O2 -I/opt/nix/store/37cahk3ls7il678l1a3g015k59rgclf7-Libsystem-osx-10.12.6/include -B/opt/nix/store/37cahk3ls7il678l1a3g015k59rgclf7-Libsystem-osx-10.12.6/lib/ -idirafter /opt/nix/store/37cahk3ls7il678l1a3g015k59rgclf7-Libsystem-osx-10.12.6/include -Wl,-rpath,/opt/nix/store/i88p6f3dznkc5n9i955m7z94icwp0gcd-gfortran-9.2.0-lib/lib -Wl,-L/opt/nix/store/37cahk3ls7il678l1a3g015k59rgclf7-Libsystem-osx-10.12.6/lib -Wl,-rpath -Wl,/opt/nix/store/37cahk3ls7il678l1a3g015k59rgclf7-Libsystem-osx-10.12.6/lib -Wl,-L/opt/nix/store/37cahk3ls7il678l1a3g015k59rgclf7-Libsystem-osx-10.12.6/lib -fno-checking -DHAVE_CONFIG_H -I. -I../../../gcc-9.2.0/libgomp -I../../../gcc-9.2.0/libgomp/config/bsd -I../../../gcc-9.2.0/libgomp/config/darwin -I../../../gcc-9.2.0/libgomp/config/posix -I../../../gcc-9.2.0/libgomp -I../../../gcc-9.2.0/libgomp/../include -Wall -pthread -Werror -O2 -I/opt/nix/store/37cahk3ls7il678l1a3g015k59rgclf7-Libsystem-osx-10.12.6/include -B/opt/nix/store/37cahk3ls7il678l1a3g015k59rgclf7-Libsystem-osx-10.12.6/lib/ -idirafter /opt/nix/store/37cahk3ls7il678l1a3g015k59rgclf7-Libsystem-osx-10.12.6/include -Wl,-rpath,/opt/nix/store/i88p6f3dznkc5n9i955m7z94icwp0gcd-gfortran-9.2.0-lib/lib -Wl,-L/opt/nix/store/37cahk3ls7il678l1a3g015k59rgclf7-Libsystem-osx-10.12.6/lib -Wl,-rpath -Wl,/opt/nix/store/37cahk3ls7il678l1a3g015k59rgclf7-Libsystem-osx-10.12.6/lib -Wl,-L/opt/nix/store/37cahk3ls7il678l1a3g015k59rgclf7-Libsystem-osx-10.12.6/lib -MT alloc.lo -MD -MP -MF .deps/alloc.Tpo -c ../../../gcc-9.2.0/libgomp/alloc.c  -fno-common -DPIC -o .libs/alloc.o
../../../gcc-9.2.0/libgomp/alloc.c: In function 'gomp_aligned_alloc':
../../../gcc-9.2.0/libgomp/alloc.c:69:9: error: implicit declaration of function 'aligned_alloc' [-Werror=implicit-function-declaration]
   69 |   ret = aligned_alloc (al, size);
      |         ^~~~~~~~~~~~~
../../../gcc-9.2.0/libgomp/alloc.c:69:9: error: incompatible implicit declaration of built-in function 'aligned_alloc' [-Werror]
../../../gcc-9.2.0/libgomp/alloc.c:32:1: note: include '<stdlib.h>' or provide a declaration of 'aligned_alloc'
   31 | #include "libgomp.h"
  +++ |+#include <stdlib.h>
   32 | #include <stdlib.h>
cc1: all warnings being treated as errors
make[5]: *** [Makefile:787: alloc.lo] Error 1
make[5]: *** Waiting for unfinished jobs....

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:

checking for aligned_alloc... yes

Aha, now that's suspicious. The stdlib.h header in /opt/nix/store/37cahk3ls7il678l1a3g015k59rgclf7-Libsystem-osx-10.12.6/include/ actually doesn't have aligned_alloc!

~/Desktop $ fgrep -r aligned_alloc /opt/nix/store/37cahk3ls7il678l1a3g015k59rgclf7-Libsystem-osx-10.12.6/include/
~/Desktop $

How did the configure script find it?

Here's a look at libgomp's config.log file:

configure:15826: checking for aligned_alloc
configure:15826: /private/var/folders/d4/n6djsq8x5dv0jfx84hzl0v000000gn/T/nix-build-gfortran-9.2.0.drv-0/build/./gcc/xgcc -B/private/var/folders/d4/n6djsq8x5dv0jfx84hzl0v000000gn/T/nix-build-gfortran-9.2.0.drv-0/build/./gcc/ -O2 -I/opt/nix/store/37cahk3ls7il678l1a3g015k59rgclf7-Libsystem-osx-10.12.6/include -B/opt/nix/store/37cahk3ls7il678l1a3g015k59rgclf7-Libsystem-osx-10.12.6/lib/ -idirafter /opt/nix/store/37cahk3ls7il678l1a3g015k59rgclf7-Libsystem-osx-10.12.6/include -Wl,-rpath,/opt/nix/store/i88p6f3dznkc5n9i955m7z94icwp0gcd-gfortran-9.2.0-lib/lib -Wl,-L/opt/nix/store/37cahk3ls7il678l1a3g015k59rgclf7-Libsystem-osx-10.12.6/lib -Wl,-rpath -Wl,/opt/nix/store/37cahk3ls7il678l1a3g015k59rgclf7-Libsystem-osx-10.12.6/lib -Wl,-L/opt/nix/store/37cahk3ls7il678l1a3g015k59rgclf7-Libsystem-osx-10.12.6/lib   -fno-checking -o conftest -O2 -I/opt/nix/store/37cahk3ls7il678l1a3g015k59rgclf7-Libsystem-osx-10.12.6/include -B/opt/nix/store/37cahk3ls7il678l1a3g015k59rgclf7-Libsystem-osx-10.12.6/lib/ -idirafter /opt/nix/store/37cahk3ls7il678l1a3g015k59rgclf7-Libsystem-osx-10.12.6/include -Wl,-rpath,/opt/nix/store/i88p6f3dznkc5n9i955m7z94icwp0gcd-gfortran-9.2.0-lib/lib -Wl,-L/opt/nix/store/37cahk3ls7il678l1a3g015k59rgclf7-Libsystem-osx-10.12.6/lib -Wl,-rpath -Wl,/opt/nix/store/37cahk3ls7il678l1a3g015k59rgclf7-Libsystem-osx-10.12.6/lib -Wl,-L/opt/nix/store/37cahk3ls7il678l1a3g015k59rgclf7-Libsystem-osx-10.12.6/lib -pthread  -Wl,-rpath,/opt/nix/store/i88p6f3dznkc5n9i955m7z94icwp0gcd-gfortran-9.2.0-lib/lib -Wl,-L/opt/nix/store/37cahk3ls7il678l1a3g015k59rgclf7-Libsystem-osx-10.12.6/lib -Wl,-rpath -Wl,/opt/nix/store/37cahk3ls7il678l1a3g015k59rgclf7-Libsystem-osx-10.12.6/lib -Wl,-L/opt/nix/store/37cahk3ls7il678l1a3g015k59rgclf7-Libsystem-osx-10.12.6/lib conftest.c -ldl  >&5
conftest.c:70:6: warning: conflicting types for built-in function 'aligned_alloc'; expected 'void *(long unsigned int,  long unsigned int)' [-Wbuiltin-declaration-mismatch]
   70 | char aligned_alloc ();
      |      ^~~~~~~~~~~~~
conftest.c:58:1: note: 'aligned_alloc' is declared in header '<stdlib.h>'
   57 | # include <limits.h>
   58 | #else
configure:15826: $? = 0
configure:15826: result: yes

So, here's my hypothesis:

  • GCC recognizes aligned_alloc as a builtin procedure and handles it specially.
  • The bootstrap compiler xgcc uses GCC's special handling for aligned_alloc but also uses the standard library in [nix-store]/[hash]-Libsystem-osx-10.12.6.
  • During configuration, xgcc converts what should be an error about missing aligned_alloc to a warning about how it has been implicitly declared.
  • During compilation, xgcc properly throws an error about missing aligned_alloc.

@Calvin-L
Copy link
Contributor

New hypothesis: this issue is specific to MacOS 10.15 (Catalina). The 10.15 system libraries include aligned_alloc while the 10.14 and earlier libraries do not:

~/Desktop $ fgrep -r aligned_alloc /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr       
~/Desktop $ fgrep -r aligned_alloc /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr
/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/malloc/_malloc.h:void    *aligned_alloc(size_t __alignment, size_t __size) __result_use_check __alloc_size(2) __OSX_AVAILABLE(10.15) __IOS_AVAILABLE(13.0) __TVOS_AVAILABLE(13.0) __WATCHOS_AVAILABLE(6.0);
[...many more results omitted...]

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 aligned_alloc is linkable but not present in the headers.

Calvin-L added a commit to Calvin-L/nixpkgs that referenced this issue Mar 19, 2020
@Calvin-L
GCC: fix compilation on MacOS 10.15
3a79681 
MacOS 10.15 now includes "aligned_alloc".  Disagreement between the
headers and the binaries about whether aligned_alloc exists leads to
a compilation failure (see NixOS#73319 and the detailed comment in this
commit).
@Calvin-L Calvin-L mentioned this issue Mar 19, 2020
Merged
10 tasks
@prusnak prusnak added the 6.topic: darwin Running or building packages on Darwin label May 9, 2020
@stale
Copy link

stale bot commented Nov 5, 2020

I marked this as stale due to inactivity. → More info

@stale stale bot added the 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md label Nov 5, 2020
@SuperSandro2000
Copy link
Member

Fixed by #82921

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
0.kind: bug 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md 6.topic: darwin Running or building packages on Darwin
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Fix GCC compilation on MacOS 10.15 Calvin-L/nixpkgs
7 participants
@prusnak @tbenst @Calvin-L @Slabity @hlolli @SuperSandro2000 @GTrunSec