https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90558
Bug ID: 90558
Summary: '_Atomic does not name a type' error resurfaces when
building with old headers on OSX Mojave
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: townsend at astro dot wisc.edu
Target Milestone: ---
I'm running into a bug building on OSX Mojave, which seems to be tied into the
problems with _Atomic in Apple's system headers. The error itself is:
/Users/townsend/devel/sdk2/build/gcc-build/./prev-gcc/xg++
-B/Users/townsend/devel/sdk2/build/gcc-build/./prev-gcc/
-B/Applications/mesasdk-dev/x86_64-apple-darwin18.5.0/bin/ -nostdinc++
-B/Users/townsend/devel/sdk2/build/gcc-build/prev-x86_64-apple-darwin18.5.0/libstdc++-v3/src/.libs
-B/Users/townsend/devel/sdk2/build/gcc-build/prev-x86_64-apple-darwin18.5.0/libstdc++-v3/libsupc++/.libs
-I/Users/townsend/devel/sdk2/build/gcc-build/prev-x86_64-apple-darwin18.5.0/libstdc++-v3/include/x86_64-apple-darwin18.5.0
-I/Users/townsend/devel/sdk2/build/gcc-build/prev-x86_64-apple-darwin18.5.0/libstdc++-v3/include
-I/Users/townsend/devel/sdk2/build/gcc/libstdc++-v3/libsupc++
-L/Users/townsend/devel/sdk2/build/gcc-build/prev-x86_64-apple-darwin18.5.0/libstdc++-v3/src/.libs
-L/Users/townsend/devel/sdk2/build/gcc-build/prev-x86_64-apple-darwin18.5.0/libstdc++-v3/libsupc++/.libs
-fno-PIE -c -DSTANDARD_STARTFILE_PREFIX=\"../../../\"
-DSTANDARD_EXEC_PREFIX=\"/Applications/mesasdk-dev/lib/gcc/\"
-DSTANDARD_LIBEXEC_PREFIX=\"/Applications/mesasdk-dev/libexec/gcc/\"
-DDEFAULT_TARGET_VERSION=\"9.1.0\"
-DDEFAULT_REAL_TARGET_MACHINE=\"x86_64-apple-darwin18.5.0\"
-DDEFAULT_TARGET_MACHINE=\"x86_64-apple-darwin18.5.0\"
-DSTANDARD_BINDIR_PREFIX=\"/Applications/mesasdk-dev/bin/\"
-DTOOLDIR_BASE_PREFIX=\"../../../../\" -DACCEL_DIR_SUFFIX=\"\"
-DTARGET_SYSTEM_ROOT=\"/\" -DENABLE_SHARED_LIBGCC -DCONFIGURE_SPECS="\"\""
-DTOOL_INCLUDE_DIR=\"/Applications/mesasdk-dev/lib/gcc/x86_64-apple-darwin18.5.0/9.1.0/../../../../x86_64-apple-darwin18.5.0/include\"
-DNATIVE_SYSTEM_HEADER_DIR=\"/usr/include\" -DIN_GCC_FRONTEND -g -O2
-fno-checking -gtoggle -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H
-I. -Ifortran -I/Users/townsend/devel/sdk2/build/gcc/gcc
-I/Users/townsend/devel/sdk2/build/gcc/gcc/fortran
-I/Users/townsend/devel/sdk2/build/gcc/gcc/../include
-I/Users/townsend/devel/sdk2/build/gcc/gcc/../libcpp/include
-I/Applications/mesasdk-dev/include -I/Applications/mesasdk-dev/include
-I/Applications/mesasdk-dev/include
-I/Users/townsend/devel/sdk2/build/gcc/gcc/../libdecnumber
-I/Users/townsend/devel/sdk2/build/gcc/gcc/../libdecnumber/dpd
-I../libdecnumber -I/Users/townsend/devel/sdk2/build/gcc/gcc/../libbacktrace
-o fortran/gfortranspec.o -MT fortran/gfortranspec.o -MMD -MP -MF
fortran/.deps/gfortranspec.TPo
/Users/townsend/devel/sdk2/build/gcc/gcc/fortran/gfortranspec.c
In file included from /usr/include/sys/sysctl.h:83,
from
/Users/townsend/devel/sdk2/build/gcc/gcc/config/darwin-driver.c:30:
/usr/include/sys/ucred.h:94:2: error: '_Atomic' does not name a type
94 | _Atomic u_long cr_ref; /* reference count */
| ^~~~~~~
make[3]: *** [darwin-driver.o] Error 1
make[3]: *** Waiting for unfinished jobs....
rm gfortran.pod gcc.pod
make[2]: *** [all-stage2-gcc] Error 2
make[1]: *** [stage2-bubble] Error 2
make: *** [all] Error 2
What makes this instance of the bug rather different than other bug reports
I've seen, is that I'm compiling using an old set of system headers (as
provided by the Xcode SDK for OSX 10.10). You can see this from my configure
invocation:
/Users/townsend/devel/sdk2/build/gcc/configure CC=
--build=x86_64-apple-darwin18.5.0 --prefix=/Applications/mesasdk-dev
--with-gmp=/Applications/mesasdk-dev --with-mpfr=/Applications/mesasdk-dev
--with-mpc=/Applications/mesasdk-dev --enable-languages=c,c++,fortran
--disable-multilib --disable-nls --disable-libsanitizer --with-sysroot=/
--with-build-sysroot=/Users/townsend/devel/sdk2/build/xcode
The messing around with --with-sysroot and --with-build-sysroot is so that the
resulting compiler can be used on older OSX versions, without any undefined
symbols cropping up. My understanding of these flags is that:
*) during the compiler and library build, system headers will be obtained from
/Users/townsend/devel/sdk2/build/xcode/usr/include -- here, the xcode subdir
contains the SDK for OSX 10.10, including headers
*) the built compiler, however, will obtain system headers from /usr/include.
Running fixheaders is usually required to make sure these system headers are
cleaned up.
Using this approach, I've had success in building earlier versions of gcc (in
particular, 8.3.0). But with 9.1, things seem to come apart. It seems the build
process is at some point grabbing headers from inside /usr/include, which --
from my understanding -- it shouldn't; until the build is complete, it should
be getting headers from the xcode subdir.
cheers,
Rich
