Opened 5 years ago

Closed 3 years ago

#57937 closed defect (fixed)

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

Reported by: aszostak-partner-eso-org Owned by:
Priority: Normal Milestone:
Component: ports Version: 2.5.4
Keywords: Cc: astroboylrx (Rixin Li), cooljeanius (Eric Gallager)
Port: gcc7 gcc8 gcc9

Description

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.

Change History (12)

comment:1 Changed 5 years ago by 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

comment:2 Changed 5 years ago by yan12125 (Chih-Hsuan Yen)

Cc: yan12125 added

comment:3 Changed 5 years ago by 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.

comment:4 Changed 5 years ago by 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?

Last edited 5 years ago by jmon12 (previous) (diff)

comment:5 Changed 5 years ago by astroboylrx (Rixin Li)

Cc: astroboylrx added

comment:6 Changed 4 years ago by abouteiller (Aurelien Bouteiller)

This problem has reappeared with xcodebuild v11

xcodebuild -version
Xcode 11.0
Build version 11A420a

This should be promoted to severe.

comment:7 Changed 4 years ago by 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.

comment:8 Changed 4 years ago by yan12125 (Chih-Hsuan Yen)

Cc: yan12125 removed

comment:9 in reply to:  4 Changed 4 years ago by 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?

Last edited 4 years ago by jmon12 (previous) (diff)

comment:10 Changed 4 years ago by cooljeanius (Eric Gallager)

Cc: cooljeanius added

comment:11 Changed 4 years ago by 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.

Last edited 4 years ago by jmon12 (previous) (diff)

comment:12 Changed 3 years ago by kencu (Ken)

Resolution: fixed
Status: newclosed

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.

Note: See TracTickets for help on using tickets.