Re: gcc/g++ failures after xcode11 update

[Jack Howarth]

Beyond the /usr/include issue, Xcode 11 should be problematic when its
bundled 10.15 SDK is used under either Mojave or Catalina due to the
enforced use of the availability attribute in the headers.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90835


On Wed, Sep 25, 2019 at 5:46 AM Chris Jones 
wrote:

>
> >> (*) The package to add back /usr/include currently does not exist in
> >> 10.15 beta, so unless it reappears come final release this is going to
> >> be more of a problem there….
> >
> > This package is not going to be coming back:
> >
> https://developer.apple.com/documentation/xcode_release_notes/xcode_10_release_notes#3035623
> >
>
> Indeed, it is not at all unexpected to no longer have this option with
> Xcode 11.
>

Re: gcc/g++ failures after xcode11 update

[Chris Jones]

(*) The package to add back /usr/include currently does not exist in 
10.15 beta, so unless it reappears come final release this is going to 
be more of a problem there….


This package is not going to be coming back: 
https://developer.apple.com/documentation/xcode_release_notes/xcode_10_release_notes#3035623




Indeed, it is not at all unexpected to no longer have this option with 
Xcode 11.

Re: gcc/g++ failures after xcode11 update

[Saagar Jha]

Saagar Jha

> On Sep 24, 2019, at 01:56, Christopher Jones  wrote:
> 
> Hi,
> 
> Note the error is not specific to gcc. Macports clang has the same problem.
> 
>  > clang++-mp-8.0 -O3 ./main.cpp 
> In file included from ./main.cpp:1:
> In file included from 
> /opt/local/libexec/llvm-8.0/bin/../include/c++/v1/iostream:38:
> In file included from 
> /opt/local/libexec/llvm-8.0/bin/../include/c++/v1/ios:215:
> In file included from 
> /opt/local/libexec/llvm-8.0/bin/../include/c++/v1/iosfwd:96:
> /opt/local/libexec/llvm-8.0/bin/../include/c++/v1/wchar.h:119:15: fatal 
> error: 'wchar.h' file not found
> #include_next 
>   ^
> 1 error generated.
> 
> The issue is both macports clang and gcc rely (by default) on /usr/include 
> being present, and this is no longer present by default with Xcode 11, and 
> even if you previously had it was likely wiped out with the last update.
> 
> Note, with 10.14 at least (*) you can add back /usr/include by following the 
> instructions in 
> 
> https://apple.stackexchange.com/questions/337940/why-is-usr-include-missing-i-have-xcode-and-command-line-tools-installed-moja
>  
> 
> 
> or, as you say below, explicitly giving the include path in some way, such as 
> the suggestion below.
> 
> cheers Chris
> 
> (*) The package to add back /usr/include currently does not exist in 10.15 
> beta, so unless it reappears come final release this is going to be more of a 
> problem there….

This package is not going to be coming back: 
https://developer.apple.com/documentation/xcode_release_notes/xcode_10_release_notes#3035623
 


>> On 24 Sep 2019, at 7:09 am, Joshua Root > > wrote:
>> 
>> On 2019-9-24 15:31 , Mihir Luthra wrote:
>>> Hi,
>>> 
>>> After the xcode update, there have been many question on stackoverflow
>>> regarding gcc and g++ linking fails. Any ideas on what can be done?
>>> 
>>> https://stackoverflow.com/questions/58072318/cannot-link-any-c-program-with-gcc-on-mac-mojave
>>>  
>>> 
>>> 
>>> https://stackoverflow.com/questions/58073301/linker-error-when-trying-to-use-lzma-in-boostiostreams-from-macports
>>> 
>>> https://stackoverflow.com/questions/58071057/macports-g-fails-to-find-headers-after-recent-xcode-update
>>> 
>>> Mihir
>> 
>> Does passing -isysroot`xcrun --show-sdk-path` to the compiler not work?
>> 
>> While that should make it find headers again, I don't know how many bugs
>> it will uncover. I'm not sure how we would make this work out of the box
>> for everyone, since AIUI, gcc needs to apply different fixups to the
>> system headers depending on the SDK version and does so at build time.
>> So Apple taking away not only the SDK corresponding to the current OS
>> version but also /usr/include is quite problematic. We can ship a gcc
>> supporting the 10.14 SDK or the 10.15 SDK, but not both.
>> 
>> Rebuilding gcc from source would also work.
>> 
>> - Josh
> 

Re: gcc/g++ failures after xcode11 update

[Ken Cunningham]

> The issue is both macports clang and gcc rely (by default) on /usr/include 
> being present, and this is no longer present by default with Xcode 11

Not exactly. The full logic was outlined by Jeremy here:

https://trac.macports.org/ticket/57612#comment:18 



TBH, I’m not sure we should ever be baking an -isysroot into any build files. 
It’s too fragile.


Jeremy’s suggestion was to either let xcrun decide how to find the correct SDK, 
or if we wanted to set it ourselves, set the SDKROOT.

>




The clang front end (cfe) then uses that env var like this:

https://clang.llvm.org/doxygen/Darwin_8cpp_source.html 


void Darwin::AddDeploymentTarget(DerivedArgList ) const {
 <> 1655   const OptTable  = getDriver 
().getOpts
 
();
 <> 1656 
 <> 1657   // Support allowing the SDKROOT environment variable used by xcrun 
and other
 <> 1658   // Xcode tools to define the default sysroot, by making it the 
default for
 <> 1659   // isysroot.
 <> 1660   if (const Arg *A = Args.getLastArg(options::OPT_isysroot)) {
 <> 1661 // Warn if the path does not exist.
 <> 1662 if (!getVFS 
().exists(A->getValue()))
 <> 1663   getDriver 
().Diag
 
(clang::diag::warn_missing_sysroot)
 << A->getValue();
 <> 1664   } else {
 <> 1665 if (char *env = ::getenv("SDKROOT")) {
 <> 1666   // We only use this value as the default if it is an absolute 
path,
 <> 1667   // exists, and it is not the root path.
 <> 1668   if (llvm::sys::path::is_absolute(env) && getVFS 
().exists(env)
 &&
 <> 1669   StringRef(env) != "/") {
 <> 1670 Args.append(Args.MakeSeparateArg(
 <> 1671 nullptr, Opts.getOption(options::OPT_isysroot), env));
 <> 1672   }
 <> 1673 }
 <> 1674   }
 <> 1675 



I have tried the route of setting SDKROOT, with some success.

>


Best,

Ken

Re: gcc/g++ failures after xcode11 update

[Christopher Jones]

Hi,

Note the error is not specific to gcc. Macports clang has the same problem.

 > clang++-mp-8.0 -O3 ./main.cpp 
In file included from ./main.cpp:1:
In file included from 
/opt/local/libexec/llvm-8.0/bin/../include/c++/v1/iostream:38:
In file included from /opt/local/libexec/llvm-8.0/bin/../include/c++/v1/ios:215:
In file included from 
/opt/local/libexec/llvm-8.0/bin/../include/c++/v1/iosfwd:96:
/opt/local/libexec/llvm-8.0/bin/../include/c++/v1/wchar.h:119:15: fatal error: 
'wchar.h' file not found
#include_next 
  ^
1 error generated.

The issue is both macports clang and gcc rely (by default) on /usr/include 
being present, and this is no longer present by default with Xcode 11, and even 
if you previously had it was likely wiped out with the last update.

Note, with 10.14 at least (*) you can add back /usr/include by following the 
instructions in 

https://apple.stackexchange.com/questions/337940/why-is-usr-include-missing-i-have-xcode-and-command-line-tools-installed-moja
 


or, as you say below, explicitly giving the include path in some way, such as 
the suggestion below.

cheers Chris

(*) The package to add back /usr/include currently does not exist in 10.15 
beta, so unless it reappears come final release this is going to be more of a 
problem there….

> On 24 Sep 2019, at 7:09 am, Joshua Root  wrote:
> 
> On 2019-9-24 15:31 , Mihir Luthra wrote:
>> Hi,
>> 
>> After the xcode update, there have been many question on stackoverflow
>> regarding gcc and g++ linking fails. Any ideas on what can be done?
>> 
>> https://stackoverflow.com/questions/58072318/cannot-link-any-c-program-with-gcc-on-mac-mojave
>> 
>> https://stackoverflow.com/questions/58073301/linker-error-when-trying-to-use-lzma-in-boostiostreams-from-macports
>> 
>> https://stackoverflow.com/questions/58071057/macports-g-fails-to-find-headers-after-recent-xcode-update
>> 
>> Mihir
> 
> Does passing -isysroot`xcrun --show-sdk-path` to the compiler not work?
> 
> While that should make it find headers again, I don't know how many bugs
> it will uncover. I'm not sure how we would make this work out of the box
> for everyone, since AIUI, gcc needs to apply different fixups to the
> system headers depending on the SDK version and does so at build time.
> So Apple taking away not only the SDK corresponding to the current OS
> version but also /usr/include is quite problematic. We can ship a gcc
> supporting the 10.14 SDK or the 10.15 SDK, but not both.
> 
> Rebuilding gcc from source would also work.
> 
> - Josh



smime.p7s
Description: S/MIME cryptographic signature

Re: gcc/g++ failures after xcode11 update

[Joshua Root]

On 2019-9-24 15:31 , Mihir Luthra wrote:
> Hi,
> 
> After the xcode update, there have been many question on stackoverflow
> regarding gcc and g++ linking fails. Any ideas on what can be done?
> 
> https://stackoverflow.com/questions/58072318/cannot-link-any-c-program-with-gcc-on-mac-mojave
> 
> https://stackoverflow.com/questions/58073301/linker-error-when-trying-to-use-lzma-in-boostiostreams-from-macports
> 
> https://stackoverflow.com/questions/58071057/macports-g-fails-to-find-headers-after-recent-xcode-update
> 
> Mihir

Does passing -isysroot`xcrun --show-sdk-path` to the compiler not work?

While that should make it find headers again, I don't know how many bugs
it will uncover. I'm not sure how we would make this work out of the box
for everyone, since AIUI, gcc needs to apply different fixups to the
system headers depending on the SDK version and does so at build time.
So Apple taking away not only the SDK corresponding to the current OS
version but also /usr/include is quite problematic. We can ship a gcc
supporting the 10.14 SDK or the 10.15 SDK, but not both.

Rebuilding gcc from source would also work.

- Josh