gcc9 @9-20181007_1: Compiler fails for trivial program indicating that _stdio.h is missing (also fails for gcc7 and gcc8).

[aszostak-partner-eso-org]

When I attempt to use gcc9 from MacPorts to compile the following trivial program conftest.c,

#include <stdio.h>
int
main ()
{
FILE *f = fopen ("conftest.out", "w");
 return ferror (f) || fclose (f) != 0;

  ;
  return 0;
}

I get the following error:

$ /opt/local/bin/gcc-mp-9 -o conftest -pipe -Os -m64 -I/opt/local/include -L/opt/local/lib -Wl,-headerpad_max_install_names conftest.c
In file included from conftest.c:2:
/opt/local/lib/gcc9/gcc/x86_64-apple-darwin17/9.0.0/include-fixed/stdio.h:78:10: fatal error: _stdio.h: No such file or directory
78 | #include <_stdio.h>
   |          ^~~~~~~~~~
compilation terminated.

I also get the same error if trying to compile with gcc7:

$ /opt/local/bin/gcc-mp-7 -o conftest -pipe -Os -m64 -I/opt/local/include -L/opt/local/lib -Wl,-headerpad_max_install_names conftest.c
In file included from conftest.c:2:0:
/opt/local/lib/gcc7/gcc/x86_64-apple-darwin17/7.4.0/include-fixed/stdio.h:78:10: fatal error: _stdio.h: No such file or directory
 #include <_stdio.h>
          ^~~~~~~~~~
compilation terminated.

And the same error with gcc8:

$ /opt/local/bin/gcc-mp-8 -o conftest -pipe -Os -m64 -I/opt/local/include -L/opt/local/lib -Wl,-headerpad_max_install_names conftest.c
In file included from conftest.c:2:
/opt/local/lib/gcc8/gcc/x86_64-apple-darwin17/8.2.0/include-fixed/stdio.h:78:10: fatal error: _stdio.h: No such file or directory
 #include <_stdio.h>
          ^~~~~~~~~~
compilation terminated.

This is happening on MacOS 10.13.6 with Xcode command line tools 9.

[yan12125 (Chih-Hsuan Yen)]

This seems an Xcode 9 issue as Xcode 10 works (1). Could you upgrade Xcode and try again?

1. ​https://github.com/macports/macports-ports/pull/3923#issuecomment-476036983

[jmon12]

Hi all, I'm experiencing the same issue with a simple hello world program. I'm getting exactly the same error as mentioned above: _stdio.h is not found. The following compilers have been tested:
1) macports' gcc5,6,7,8 -> failure
2) apple's clang (Apple LLVM version 10.0.1 (clang-1001.0.46.4) -> success
3) macports's clang 8.0.0 -> success

The command line tools version 10.3.0.0.1.1562985497 is installed. The _stdio.h file is located at /usr/include as it should. Is there something wrong with my macports installation? I'm available if you need any supplementary information.

[jmon12]

Hi again, I think having found the problem. After running:

/opt/local/bin/gcc-mp-5 -print-prog-name=cc1
/opt/local/libexec/gcc/x86_64-apple-darwin18/5.5.0/cc1

/opt/local/libexec/gcc/x86_64-apple-darwin18/5.5.0/cc1 -v
ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/opt/local/include"
ignoring nonexistent directory "/opt/local/lib/gcc5/gcc/x86_64-apple-darwin18/5.5.0/../../../../../x86_64-apple-darwin18/include"
ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include"
ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/System/Library/Frameworks"
ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/Library/Frameworks"
#include "..." search starts here:
#include <...> search starts here:
 /opt/local/lib/gcc5/gcc/x86_64-apple-darwin18/5.5.0/include
 /opt/local/lib/gcc5/gcc/x86_64-apple-darwin18/5.5.0/include-fixed
End of search list.

I finally understood that gcc is actually not checking /usr/include (and /usr/lib) which is the default path where the CommandLineTOols SDKs is installed.

I think it has been changed since I'm pretty sure that previous versions of the gcc port did check /usr/include. A fix for now is to use gcc -I/usr/include -L/usr/lib... Is there a way to change this default behavior? i.e. add /usr/include and /usr/lib to the default searching path of macports' gcc?

[abouteiller (Aurelien Bouteiller)]

This problem has reappeared with xcodebuild v11

xcodebuild -version
Xcode 11.0
Build version 11A420a

This should be promoted to severe.

[kencu (Ken)]

No version of gcc works with Xcode 11 at present. Please see many other open tickets for explanations, links to gcc bug reports, and suggestions.

[jmon12]

Replying to jmon12: Sorry for talking to myself again here! My previous fix is not completely right, since the priority of -I and -L is too high, i.e. doesn't treat them as system includes/libraries directories. (see gcc documentation ​https://gcc.gnu.org/onlinedocs/gcc/Directory-Options.html for priorities of include and L flags). Instead, one should use the following (if includes and libraries or in /usr/include and /usr/lib):

gcc --sysroot=/ -Wl,-syslibroot,/

The linker option -Wl,-syslibroot,/ is necessary in my case for a reason that I don't understand. From the documentation ​https://gcc.gnu.org/onlinedocs/gcc/Directory-Options.html, --sysroot should affect both header/includes and libraries search directories.

Hi again, I think having found the problem. After running:

/opt/local/bin/gcc-mp-5 -print-prog-name=cc1
/opt/local/libexec/gcc/x86_64-apple-darwin18/5.5.0/cc1

/opt/local/libexec/gcc/x86_64-apple-darwin18/5.5.0/cc1 -v
ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/opt/local/include"
ignoring nonexistent directory "/opt/local/lib/gcc5/gcc/x86_64-apple-darwin18/5.5.0/../../../../../x86_64-apple-darwin18/include"
ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include"
ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/System/Library/Frameworks"
ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/Library/Frameworks"
#include "..." search starts here:
#include <...> search starts here:
 /opt/local/lib/gcc5/gcc/x86_64-apple-darwin18/5.5.0/include
 /opt/local/lib/gcc5/gcc/x86_64-apple-darwin18/5.5.0/include-fixed
End of search list.

I finally understood that gcc is actually not checking /usr/include (and /usr/lib) which is the default path where the CommandLineTOols SDKs is installed.

I think it has been changed since I'm pretty sure that previous versions of the gcc port did check /usr/include. A fix for now is to use gcc -I/usr/include -L/usr/lib... Is there a way to change this default behavior? i.e. add /usr/include and /usr/lib to the default searching path of macports' gcc?

[jmon12]

For the sake of documentation: building gcc from source uses the default sysroot (i.e. /) which solves my problem. Check ticket #58260 if you have problem to build them from source.

However, I don't understand why it's removed from the default builds of gcc. It could have been left together with the Xcode-specific ones.

[kencu (Ken)]

I believe this has been fixed now by changes in base and the noted ports to spec an existing SDK.

please reopen with new information if you find this is still an issue.