[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