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

MacPorts noreply at macports.org
Sun Oct 20 13:22:15 UTC 2019


#57937: gcc9 @9-20181007_1: Compiler fails for trivial program indicating that
_stdio.h is missing (also fails for gcc7 and gcc8).
---------------------------------------+--------------------
  Reporter:  aszostak-partner-eso-org  |      Owner:  (none)
      Type:  defect                    |     Status:  new
  Priority:  Normal                    |  Milestone:
 Component:  ports                     |    Version:  2.5.4
Resolution:                            |   Keywords:
      Port:  gcc7 gcc8 gcc9            |
---------------------------------------+--------------------

Comment (by jmon12):

 Replying to [comment:4 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 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?

-- 
Ticket URL: <https://trac.macports.org/ticket/57937#comment:9>
MacPorts <https://www.macports.org/>
Ports system for macOS


More information about the macports-tickets mailing list