search

iains / gcc-14-branch

GCC 14 for Darwin with experimental Arm64 support. Current release 14.2-darwin-r2 [October 2024]
GNU General Public License v2.0
11 stars 3 forks source link

error: 'FILE' has not been declared in '::' #14

Closed saschasc closed 1 month ago

saschasc commented 1 month ago

I have these new errors which appear when using XCLT 16.0. With XCLT 15.3 abseil compiles without any issues. Here the log.

abseil.txt

iains commented 1 month ago

did you rebuild the compiler using the XCLT 16 SDK?

I think that this issue is fixed by https://github.com/iains/gcc-14-branch/commit/3f365c6ed2583b2b338273c16e9b3ce36d2c2229

At present, we are not necessarily able to build the compiler with XC15 SDK and then use it with XC16 SDK... (although I think if you built it against macOS14.4.sdk from XC15, it will likely work with the macOS14.5.sdk from XC16 - but you will have to be explicit about that by passing --sysroot=/path/to/SDKs/macOS14.sdk)

saschasc commented 1 month ago

did you rebuild the compiler using the XCLT 16 SDK?

Should have been a complete rebuild. But I can retest again to be sure. I will report back.

saschasc commented 1 month ago

But gcc should work with both macOS14.5.sdk and macOS15.x.sdk folders as sysroot?

Why are there two SDK folders. Can both still be used together with Sonoma (which is the current macOS on my Mac right now)?

First I will try again with the XC16.1 Beta 3 SDK (macOS15.1.sdk) folder as sysroot.

iains commented 1 month ago

But gcc should work with both macOS14.5.sdk and macOS15.x.sdk folders as sysroot?

That would be ideal (and much of the time it [GCC] does work [with more than one SDK]) - but it cannot when the SDKs have incompatible changes between them since we have to implement some fixes to the headers where they are not supportable by GCC. There have been a few incompatible changes over the years (e.g. changes to the files contained or the layout) - this one between macOS14/15 is currently biting.

Why are there two SDK folders.

clang can select the one appropriate for the target system (e.g. if building for macOS14 on macOS15. or building for macOS15 on macOS14).

Can both still be used together with Sonoma (which is the current macOS on my Mac right now)?

[IMO] you should use the macOS14 SDK when building on and targeting macOS14 (although, of course, you would expect the built binaries to run on macOS15 too).

If you want to use the macOS15 SDK you will need to build the compiler using it as the designated sysroot (--with-sysroot=/path/to/macOS15.sdk) ..

First I will try again with the XC16.1 Beta 3 SDK (macOS15.1.sdk) folder as sysroot.

I would not expect the underlying issue to have changed.

saschasc commented 1 month ago

Thanks for the detailed explanation. I used twice the macOS15.sdk when building gcc from source on macOS 14. So this could be the culprit. I will try again using the macOS14.sdk folder which is symlinking to macOS14.5.sdk as sysroot.

anddebol commented 1 month ago

Any timeline when 3f365c6 will be available in hombrew cask?

iains commented 1 month ago

Any timeline when 3f365c6 will be available in hombrew cask?

you'd need to ask that to homebrew folks - I'm not involved it the scheduling of homebrew, macports etc.

saschasc commented 1 month ago

but it cannot when the SDKs have incompatible changes between them since we have to implement some fixes to the headers where they are not supportable by GCC.

I understand. Doesn't seem like an easy situation if you always have to react. It would be great if there was more support and proactive communication from Apple.

My specific problem seems to be related to Conan which is implicitly using the macOS15.sdk folder as sysroot. This led to the problems I was having. I still need to figure out how to pass the correct SDK/sysroot to the upstream packages when they are built from source.

Thanks again @iains for the detailed explanations. That helped a lot.