https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90834
Bug ID: 90834
Summary: Header and startup objects not found on macOS 10.15
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: ro at gcc dot gnu.org
CC: iains at gcc dot gnu.org
Target Milestone: ---
Host: x86_64-apple-darwin19
Target: x86_64-apple-darwin19
Build: x86_64-apple-darwin19
When trying to build mainline on macOS 10.15 with Xcode 11 Beta, I ran into a
couple of issues:
As already mentioned in the Xcode 10 release notes, both system headers in
/usr/include nor startup objects in /usr/lib (crt*.o, dylib1*.o) are no longer
available, and the separate package that provided them in Xcode 10 is no longer
available in Xcode 11 (although this isn't specially mentioned in the Xcode 11
release notes).
For the moment, I've hacked around this by
* symlinking
/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include
to /usr/include
* symlinking
/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/System/Library/Frameworks/CoreFoundation.framework/Versions/A/Headers
to
/System/Library/Frameworks/CoreFoundation.framework/Versions/Current/Headers
and symlinking /System/Library/Frameworks/CoreFoundation.framework/Headers to
Versions/Current/Headers
* symlinking
/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/lib/{crt1,dylib1}*.o
to /usr/lib
The /usr/include part could be dealt with by configuring with
--with-native-system-header-dir, however that would tie gcc to a particular OS
version.
I've no idea if there's an easy way to handle the
/System/Library/Frameworks/CoreFoundation.framework
part.
The /usr/lib symlinks are beyond ugly, MD_STARTFILE_PREFIX could deal with that
if it weren't for the fact that the directory name is OS version dependent.
It seems gcc needs a way to handle this out of the box.
