https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90330
--- Comment #19 from Iain Sandoe <iains at gcc dot gnu.org> --- (In reply to Matt Thompson from comment #17) > > b) (remind me) what is the "--with-native-system-header-dir=/usr/include" > > meant to provide? It seems like you are maybe mixing cross-configuration > > options with native ones... > > This was my attempt to try to work around the fact that Apple no longer > supplies a /usr/include: > > https://developer.apple.com/documentation/xcode_release_notes/ > xcode_10_release_notes#3035624 > > Now, I'm not sure that gcc itself needs /usr/include, but many of the > libraries and more I compile with gcc seem to assume it. And I've gotten to > the point where I just couldn't figure out how to pass '-isysroot' down to > code like f2py (gcc is called by f2py but f2py only passes down Fortran > flags. And I just *cannot* get our CMake system to pass > CFLAGS='-isysroot...' to the gcc call within f2py). > > So, I thought I'd look around and saw that Homebrew built a little > differently: > > https://github.com/Homebrew/homebrew-core/blob/master/Formula/gcc.rb > > adding: > elsif MacOS.version >= :mojave > # System headers are no longer located in /usr/include > args << "--with-native-system-header-dir=/usr/include" > args << > "--with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk" I don't know what they intended to achieve with this. There *is* one gremlin with the sysroot being /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk which is that /usr/local/include is still a usable directory and needs to be searched *without* prepending the sysroot. This is something I want to fix during the next couple of months - but isn't necessary *unless* you've installed packages into /usr/local that you want to use. (A workaround is to add -I... so it shouldn't be a show-stopper) > My hope was perhaps this would "embed" in gcc the fact that sysroot is not > in /usr/include but was in > /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include and so f2py > would work again. > > Is it just the --with-sysroot that I'd need to "hardcode" a gcc with that > sysroot? the --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk should "just work" (modulo the gotcha about /usr/local mentioned) with no need for any additional magic. > I have tried the same configure line with gcc 8.2.0 loaded, but I get: > > checking whether we are cross compiling... configure: error: in > `/Users/mathomp4/src/GCC/gcc-9.2.0-BUILD-820loaded': > configure: error: cannot run C compiled programs. > If you meant to cross compile, use `--host'. > See `config.log' for more details If you want to use GCC as the bootstrap and it was built for a system with /usr/include [and now that directory has been removed] then you need to supply it with a sysroot explicitly as I do. CC="gcc-8-x --sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk" CXX="g++-8.x --sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk" (on the configure line) > Note, looking at Homebrew again, I do see they also build with: > > make BOOT_LDFLAGS=-Wl,-headerpad_max_install_names That is solving a different problem - where it would seem that they intend to use install_name_tool to update the install paths and are allowing the maximum space. > would that help? very unlikely.
