Opened 23 months ago

Closed 3 months ago

#59665 closed defect (worksforme)

gcc9 pre-built binary can't access system SDK with Xcode 11.2 under Mojave

Reported by: EJFielding (Eric Fielding) Owned by:
Priority: Normal Milestone:
Component: ports Version: 2.6.2
Keywords: Cc: cooljeanius (Eric Gallager), michaellass (Michael Lass)
Port: gcc9 gcc7


My MacBook running Mojave 10.14.6 has been upgraded to Xcode 11.2 (this was not my choice as my employer installs updates on our work computers). The pre-built binary for the gcc9 port has the system 10.14 SDK hard-coded to be found in the Xcode directory /Applications/, but this is not available in Xcode 11.x, including 11.2.

With gcc9 selected, I can't compile a simple configuration test that contains only #include "Python.h"

gcc conftest_0.c
In file included from /opt/local/lib/gcc9/gcc/x86_64-apple-darwin18/9.2.0
                  from /opt/local/lib/gcc9/gcc/x86_64-apple-darwin18/9.2.0
                  from conftest_0.c:2:
fixed/limits.h:194:61: error: no include path in which to search for
   194 | #include_next <limits.h>  /* recurse down to the real one */
       |                                                             ^
In file included from
                  from conftest_0.c:2:
fixed/stdio.h:78:10: fatal error: _stdio.h: No such file or directory
    78 | #include <_stdio.h>
       |          ^~~~~~~~~~
compilation terminated.

The output of cpp -v shows the problem:

cpp -v
Using built-in specs.
Target: x86_64-apple-darwin18
Configured with: /opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_gcc9/gcc9/work/gcc-9.2.0/configure --prefix=/opt/local --build=x86_64-apple-darwin18 --enable-languages=c,c++,objc,obj-c++,lto,fortran --libdir=/opt/local/lib/gcc9 --includedir=/opt/local/include/gcc9 --infodir=/opt/local/share/info --mandir=/opt/local/share/man --datarootdir=/opt/local/share/gcc-9 --with-local-prefix=/opt/local --with-system-zlib --disable-nls --program-suffix=-mp-9 --with-gxx-include-dir=/opt/local/include/gcc9/c++/ --with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local --with-isl=/opt/local --enable-stage1-checking --disable-multilib --enable-lto --enable-libstdcxx-time --with-build-config=bootstrap-debug --with-as=/opt/local/bin/as --with-ld=/opt/local/bin/ld --with-ar=/opt/local/bin/ar --with-bugurl= --disable-tls --with-pkgversion='MacPorts gcc9 9.2.0_1' --with-sysroot=/Applications/
Thread model: posix
gcc version 9.2.0 (MacPorts gcc9 9.2.0_1)
COLLECT_GCC_OPTIONS='-E' '-v' '-mmacosx-version-min=10.14.0' '-asm_macosx_version_min=10.14' '-mtune=core2'
 /opt/local/libexec/gcc/x86_64-apple-darwin18/9.2.0/cc1 -E -quiet -v -D__DYNAMIC__ - -fPIC -mmacosx-version-min=10.14.0 -mtune=core2
ignoring nonexistent directory "/Applications/"
ignoring nonexistent directory "/opt/local/lib/gcc9/gcc/x86_64-apple-darwin18/9.2.0/../../../../../x86_64-apple-darwin18/include"
ignoring nonexistent directory "/Applications/"
ignoring nonexistent directory "/Applications/"
ignoring nonexistent directory "/Applications/"
#include "..." search starts here:
#include <...> search starts here:
End of search list.

I had the same problem with gcc7, and I found that I was able to get it working by forcing the installation of the command line tools from Xcode 10.3 and rebuilding the gcc7 port from source (which took more than an hour on this relatively new MacBook Pro).

Change History (5)

comment:1 Changed 23 months ago by mf2k (Frank Schima)

Keywords: gcc9 removed
Port: gcc9, gcc7gcc9 gcc7

comment:2 Changed 23 months ago by kencu (Ken)

It seems that our prebuilt gcc ports from the buildbot are built looking into Xcode. There is at least one other similar ticket #59727 out there. Hopefully will just need to revbump them to get them to rebuild against the CLTs.

comment:3 Changed 22 months ago by cooljeanius (Eric Gallager)

Cc: cooljeanius added

comment:4 Changed 9 months ago by michaellass (Michael Lass)

Cc: michaellass added

comment:5 Changed 3 months ago by kencu (Ken)

Resolution: worksforme
Status: newclosed

I believe this was initially due to no following the migration instructions. Otherwise the gcc version would not have been looking for the 10.14.sdk on BigSur.

Note: See TracTickets for help on using tickets.