gcc-13.3-darwin-r0 tag build error on macOS14 ARM

[cjones051073]

Using latest gcc gcc-13.3-darwin-r0 tag

In file included from /opt/local/var/macports/build/_Users_chris_Projects_MacPorts_ports_lang_gcc13/libgcc13/work/gcc-13.3.0/libiberty/floatformat.c:29:
:info:build /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/math.h:54:5: error: #error "Unsupported value of __FLT_EVAL_METHOD__."
:info:build    54 | #   error "Unsupported value of __FLT_EVAL_METHOD__."
:info:build       |     ^~~~~
:info:build make[3]: *** [floatformat.o] Error 1
:info:build make[3]: *** Waiting for unfinished jobs....

Full configure and build log attached main.log.gz

[iains]

:debug:main Starting logging for libgcc13 @13.2.0_4+stdlib_flag

^^^ This looks like it's related to 13.2 not 13.3?

the 13.3 branch includes:

commit 87e6cc0103369f8891c3c3a516f4d93187c2c12b
Author: Francois-Xavier Coudert <fxcoudert@gcc.gnu.org>
Date:   2023-12-11 14:56:04 +0000

    fixincludes: Update darwin_flt_eval_method for macOS 14

[cjones051073]

No it's for 13.3 ignore that first part of the log

[cjones051073]

apologies, that last log had some crude from an older 13.2 build at the start, but the bulk of it is indeed for 13.3. Here is a clean up version main.log.gz

[cjones051073]

note, the way the macports builds work is they start from the stock upstream release tarballs, but then apply a patch file generated from the tag in your repo here,

:debug:patch system:  cd "/opt/local/var/macports/build/_Users_chris_Projects_MacPorts_ports_lang_gcc13/libgcc13/work/gcc-13.3.0" && /usr/bin/patch -p0 < '/Users/chris/Projects/MacPorts/ports/lang/gcc13/files/patch-darwin-gcc-13.3.0.diff'

so the end result is what is built is exactly equivalent to your gcc-13.3-darwin-r0 tag

[cjones051073]

final small log file clean up....

main.log.gz

[cjones051073]

I should add gcc 13.2 builds just fine using the exact same procedure, applying a patch file that takes the build to your gcc-darwin-13.2-r0 tag. The issue above is new for the 13.3 release (and FWIW, I see exactly the same when attempting to build gcc 14.1 using your branch there).

[iains]

note, the way the macports builds work is they start from the stock upstream release tarballs,

Do you know which tarball is being used in this case? ( I can then check if it should include the patch I referenced ).

but then apply a patch file generated from the tag in your repo here,

:debug:patch system:  cd "/opt/local/var/macports/build/_Users_chris_Projects_MacPorts_ports_lang_gcc13/libgcc13/work/gcc-13.3.0" && /usr/bin/patch -p0 < '/Users/chris/Projects/MacPorts/ports/lang/gcc13/files/patch-darwin-gcc-13.3.0.diff'

so the end result is what is built is exactly equivalent to your gcc-13.3-darwin-r0 tag

In principle, at least.

I do build the release sources on as many systems as I have available - but, I suspect, that for 13.3 I only had x86_64 macOS14).

[iains]

I should add gcc 13.2 builds just fine using the exact same procedure, applying a patch file that takes the build to your gcc-darwin-13.2-r0 tag. The issue above is new for the 13.3 release (and FWIW, I see exactly the same when attempting to build gcc 14.1 using your branch there).

This is surprising, let me see if I can repeat it - at the moment my test hardware is building/testing a rebase from the weekend, so it will not be immediate

[cjones051073]

the tar ball is from the stock gcc release sites, e.g.

--->  Attempting to fetch gcc-13.3.0.tar.xz from ftp://ftp.lip6.fr/pub/gnu/gcc/gcc-13.3.0

but thats just the start, the p[atch file that is applied makes what is built identical to your tags here.

[iains]

final small log file clean up....

main.log.gz

one difference - I have not tried to build with Xcode 15.4 CLT .. are you able to test with 15.3?

[cjones051073]

I'm not really that keen to downgrade TBH...

[iains]

I'm not really that keen to downgrade TBH...

I do not see an Xcode 15.4 CLT .. so perhaps there's no difference in those tools; which perhaps means there's a change in the SDK.. I know FX filed a Feedback about the __FLT_EVAL_METHOD__.

@fxcoudert any ideas here?

[iains]

This patch is before the 13.3.0 tag on releases/gcc-13 - so I would have expected it to be in the release tarballs too. Perhaps there's yet another change in this in the Xcode 15.4 SDKs.. I not have those, since there's no XC15.4 CLT download.

commit 87e6cc0103369f8891c3c3a516f4d93187c2c12b
Author: Francois-Xavier Coudert <fxcoudert@gcc.gnu.org>
Date:   2023-12-11 14:56:04 +0000

    fixincludes: Update darwin_flt_eval_method for macOS 14

    On macOS 14, a guard in <math.h> changed:

    -- MacOSX13.3.sdk/usr/include/math.h 2023-04-19 01:54:44
    +++ MacOSX14.0.sdk/usr/include/math.h 2023-08-01 08:42:43
    @@ -22,0 +23 @@
    +
    @@ -43 +44 @@
    -#if __FLT_EVAL_METHOD__ == 0
    +#if __FLT_EVAL_METHOD__ == 0 || __FLT_EVAL_METHOD__ == -1
    @@ -49 +50 @@
    -#elif __FLT_EVAL_METHOD__ == 2 || __FLT_EVAL_METHOD__ == -1
    +#elif __FLT_EVAL_METHOD__ == 2

    Therefore the darwin_flt_eval_method fixincludes fix doesn't match any
    longer, leading to a large number of testsuite failures like

    /private/var/gcc/regression/master/14-gcc/build/gcc/include-fixed/math.h:69:5:
    error: #error "Unsupported value of __FLT_EVAL_METHOD__."

    where __FLT_EVAL_METHOD__ = 16.

    This patch adjusts the fix to allow for both forms.

    Tested with make check in fixincludes on x86_64-apple-darwin23.0.0 and
    verifying that <math.h> has indeed been fixed as expected.

    (backport of 93f803d53b5ccaabded9d7b4512b54da81c1c616)

[cjones051073]

The source we build starts as the official 13.3.0 tarball

:notice:fetch --->  Attempting to fetch gcc-13.3.0.tar.xz from ftp://ftp.lip6.fr/pub/gnu/gcc/gcc-13.3.0

which we then patch using a patch file generated from your repo tag

git diff --no-prefix releases/gcc-13.3.0 gcc-13.3-darwin-r0 | cat > patch-darwin-gcc-13.3.0.diff

which gets applied as

:debug:patch system:  cd "/opt/local/var/macports/build/_Users_chris_Projects_MacPorts_ports_lang_gcc13/libgcc13/work/gcc-13.3.0" && /usr/bin/patch -p0 < '/Users/chris/Projects/MacPorts/ports/lang/gcc13/files/patch-darwin-gcc-13.3.0.diff'
:info:patch patching file Makefile.def
:info:patch patching file Makefile.in
:info:patch patching file README.md
:info:patch patching file 'c++tools/Makefile.in'
<snip>

so what we end up with is precisely whatever you have in your gcc-13-3-darwin-r0 tag. So if its in that, we are using it.

[cjones051073]

for reference the patch file we apply to bring the stock release to your tagged version

patch-darwin-gcc-13.3.0.diff.gz

[cjones051073]

FWIW I just forcibly removed my CLT installation

sudo rm -rf /Library/Developer/CommandLineTools

made sure my Xcode 15.4 was update to date, and then reinstalled the CLT with

xcode-select --install

with that I tried building gcc 13.3 and get the same error.

I am not sure what you mean by 'there's no XC15.4 CLT download' ? This procedure works fine for me.

[iains]

FWIW I just forcibly removed my CLT installation

sudo rm -rf /Library/Developer/CommandLineTools

made sure my Xcode 15.4 was update to date, and then reinstalled the CLT with

xcode-select --install

with that I tried building gcc 13.3 and get the same error.

I just checked the release tarball - and FX's patch is in it ..

I am not sure what you mean by 'there's no XC15.4 CLT download' ? This procedure works fine for me.

There is no separate Xcode 15.4 CLT download on Apple's Developer website; I do not, and will not, have multiple Xcode versions installed on all my test boxes it becomes unmanageable - CLT is hard enough.

[cjones051073]

You don't have Xcode installed ? Only the CLT ?

[cjones051073]

with that I tried building gcc 13.3 and get the same error.

I just checked the release tarball - and FX's patch is in it ..

Then I guess, for me with Xcode 15.4 (and whatever CLT running xcode-select --install then provides) that patch is no longer working.

[cjones051073]

So I ran a test build, going back to your previous tag, gcc-13.2-darwin-r0. That builds just fine, on the same machine with Xcode 15.4 + CLT on which gcc-13.3-darwin-r0 fails to build. So I am not sure the issue is really the Xcode version here, and more some change between these two tags.

Here is the OK 13.2 build log for reference

main-13.2.0.log.gz

[iains]

So I ran a test build, going back to your previous tag, gcc-13.2-darwin-r0. That builds just fine, on the same machine with Xcode 15.4 + CLT on which gcc-13.3-darwin-r0 fails to build. So I am not sure the issue is really the Xcode version here, and more some change between these two tags.

two things have changed; (1) the branch has got some improvements (2) it seems that the SDK has changed, in some way.

Almost certainly updates that relate to the improved coverage of floating point types have triggered this; but it is also the case that the branch does build fine with earlier Apple SDKs using the fixincludes that are part of the current branch - so that you might need to figure out what changes are needed to those to cover the SDK version you are using.

[cjones051073]

So I ran a test build, going back to your previous tag, gcc-13.2-darwin-r0. That builds just fine, on the same machine with Xcode 15.4 + CLT on which gcc-13.3-darwin-r0 fails to build. So I am not sure the issue is really the Xcode version here, and more some change between these two tags.

two things have changed; (1) the branch has got some improvements (2) it seems that the SDK has changed, in some way.

Almost certainly updates that relate to the improved coverage of floating point types have triggered this; but it is also the case that the branch does build fine with earlier Apple SDKs using the fixincludes that are part of the current branch - so that you might need to figure out what changes are needed to those to cover the SDK version you are using.

Here is the math.h header from the error

:info:build /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/math.h:54:5: error: #error "Unsupported value of __FLT_EVAL_METHOD__."
:info:build    54 | #   error "Unsupported value of __FLT_EVAL_METHOD__."
:info:build       |     ^~~~~

from the SDK I am using (15.4) . can you compare it to what you have with 15.3 to see what has changed ? math.h.gz

[cjones051073]

b.t.w., and please bare with me here as I know next to nothing about how GCC's 'fixincludes' work, but the error I see is

:info:build /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/math.h:54:5: error: #error "Unsupported value of __FLT_EVAL_METHOD__."
:info:build    54 | #   error "Unsupported value of __FLT_EVAL_METHOD__."
:info:build       |     ^~~~~

whereas in the patch you mention above it mentions errors like

/private/var/gcc/regression/master/14-gcc/build/gcc/include-fixed/math.h:69:5:
    error: #error "Unsupported value of __FLT_EVAL_METHOD__."

Could it be for some reason in the builds I have the fixincludes are not being used at all, for some reason, hence the error message referring directly to /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/math.h instead of a temporary path like /private/var/gcc/regression/master/14-gcc/build/gcc/include-fixed/math.h ?

[cjones051073]

b.t.w. The CLT I have installed is still 15.3

DEBUG: Xcode 15.4, CLT 15.3.0.0.1.1708646388

So likely the same as what you have anyway.

[iains]

b.t.w. The CLT I have installed is still 15.3

DEBUG: Xcode 15.4, CLT 15.3.0.0.1.1708646388

So likely the same as what you have anyway.

In this case, what probably matters is the SDK in use.

[iains]

for the record I just confirmed a build of GCC-13.3-darwin-r1 on macOS14.5:

$ ./gcc/xgcc -v
Using built-in specs.
COLLECT_GCC=./gcc/xgcc
Target: aarch64-apple-darwin23
Configured with: /src-local/gcc-git-13/configure --prefix=/opt/iains/aarch64-apple-darwin23/gcc-13-3Dr1 --build=aarch64-apple-darwin23 --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk --disable-libstdcxx-pch --enable-languages=all CC=aarch64-apple-darwin23-gcc CXX=aarch64-apple-darwin23-g++
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.3.0 (GCC) 

(I'm using GCC to bootstrap, because of building Ada and D too).

[iains]

from the SDK I am using (15.4) . can you compare it to what you have with 15.3 to see what has changed ? math.h.gz

Now I am very confused - that file is the same as the one in the SDK I am using - and which [as per the comment above] built and tested fine from my branch. I'm now doing a build with clang as the bootstrap compiler (so no Ada or D).

[cjones051073]

Could it also be related to the configure options we use, which are perhaps not the usual ones (you can find an example of what we use in the logs) ?

[fxcoudert]

for reference the patch file we apply to bring the stock release to your tagged version patch-darwin-gcc-13.3.0.diff.gz

Normally the fix for that header is in GCC 13.3 upstream (https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=87e6cc0103369f8891c3c3a516f4d93187c2c12b).

Can you confirm what is the value of __FLT_EVAL_METHOD__ when the error occurs?

[cjones051073]

for reference the patch file we apply to bring the stock release to your tagged version patch-darwin-gcc-13.3.0.diff.gz

Normally the fix for that header is in GCC 13.3 upstream (https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=87e6cc0103369f8891c3c3a516f4d93187c2c12b).

Can you confirm what is the value of __FLT_EVAL_METHOD__ when the error occurs?

How would I go about doing that ?

[iains]

Could it also be related to the configure options we use, which are perhaps not the usual ones (you can find an example of what we use in the logs) ?

I looked at your configure line:

/opt/local/var/macports/build/_Users_chris_Projects_MacPorts_ports_lang_gcc13/libgcc13/work/gcc-13.3.0/configure
--prefix=/opt/local
--build=arm64-apple-darwin23 
--enable-languages=c,c++,objc,obj-c++,lto,fortran
--libdir=/opt/local/lib/libgcc
--includedir=/opt/local/include/gcc
--infodir=/opt/local/share/info
--mandir=/opt/local/share/man
--datarootdir=/opt/local/share/gcc-13
--with-local-prefix=/opt/local
--with-system-zlib
--disable-nls
--program-suffix=-mp-13
--with-gxx-include-dir=/opt/local/include/gcc/c++
--with-gmp=/opt/local
--with-mpfr=/opt/local
--with-mpc=/opt/local
--with-isl=/opt/local
--with-zstd=/opt/local
--enable-checking=release
--disable-multilib
--enable-lto
--enable-libstdcxx-time
--with-build-config=bootstrap-debug
--with-as=/opt/local/bin/as
--with-ld=/opt/local/bin/ld-classic
--with-ar=/opt/local/bin/ar
--with-bugurl=https://trac.macports.org/newticket
--enable-host-shared
--with-darwin-extra-rpath=/opt/local/lib/libgcc
--with-libiconv-prefix=/opt/local
--disable-tls
--with-gxx-libcxx-include-dir="/opt/local/libexec/gcc13/libc++/include/c++/v1"
--with-pkgversion="MacPorts gcc13 13.3.0_0+stdlib_flag" 
--with-sysroot="/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk" 

There are a some unnecessary entries (--enable-host-shared --disable-multilib --enable-lto) and one that is surprising - not quite sure how some functionality would work with it : --disable-tls.

However, I don't see anything obvious to explain this - unless somehow there's something in your configured include path --includedir=/opt/local/include/gcc that's somehow interfering.

[iains]

from the SDK I am using (15.4) . can you compare it to what you have with 15.3 to see what has changed ? math.h.gz

Now I am very confused - that file is the same as the one in the SDK I am using - and which [as per the comment above] built and tested fine from my branch. I'm now doing a build with clang as the bootstrap compiler (so no Ada or D).

For the record, my bootstrap using clang also worked fine - so it's puzzling - almost as if the starting tarball was somehow corrupted - as FX says, the patch that fixed the issue should already have been in that.

[cjones051073]

from the SDK I am using (15.4) . can you compare it to what you have with 15.3 to see what has changed ? math.h.gz

Now I am very confused - that file is the same as the one in the SDK I am using - and which [as per the comment above] built and tested fine from my branch. I'm now doing a build with clang as the bootstrap compiler (so no Ada or D).

For the record, my bootstrap using clang also worked fine - so it's puzzling - almost as if the starting tarball was somehow corrupted - as FX says, the patch that fixed the issue should already have been in that.

the source tree we are building is precisely the same as this tag

https://github.com/iains/gcc-13-branch/releases/tag/gcc-13.3-darwin-r0

[cjones051073]

Just on the tls question, the comments surrounding why we disabled this are

# see https://lists.macports.org/pipermail/macports-dev/2017-August/036209.html
# --disable-tls does not limit functionality
# it only determines how std::call_once works
configure.args-append  --disable-tls

I'll have to check if thats still needed, but its there with 13.2 as well and doesn't seem to do any harm there.

[iains]

from the SDK I am using (15.4) . can you compare it to what you have with 15.3 to see what has changed ? math.h.gz

Now I am very confused - that file is the same as the one in the SDK I am using - and which [as per the comment above] built and tested fine from my branch. I'm now doing a build with clang as the bootstrap compiler (so no Ada or D).

For the record, my bootstrap using clang also worked fine - so it's puzzling - almost as if the starting tarball was somehow corrupted - as FX says, the patch that fixed the issue should already have been in that.

the source tree we are building is precisely the same as this tag

https://github.com/iains/gcc-13-branch/releases/tag/gcc-13.3-darwin-r0

OK; so we have to figure out where the difference is coming from, since that builds fine for me on macOS14.5 with either GCC or clang as the bootstrap compiler.

Are you able to look at gcc/include-fixed in the failed build tree? (you might need to look at gcc-prev/include-fixed if you fail in stage2+

if you manually run make in the failed directory and then get the failed compile line; we can then do things like adding -H to print out the header searches as they happen - that should tell you where the math.h is coming from.

[cjones051073]

Regarding /opt/local/include/gcc this is an include area provided by the gcc13 port itself.

Now, it is true when I build the gcc 13.3 update, I do have the previous gcc 13.2 port version installed, so that dir is populated. This is the usual way things work within macports when a port is upgraded, but let me run a check to see if in this case the presence of this include area from the 13.2 build is interfering in some way.

[cjones051073]

Regarding /opt/local/include/gcc this is an include area provided by the gcc13 port itself.

Now, it is true when I build the gcc 13.3 update, I do have the previous gcc 13.2 port version installed, so that dir is populated. This is the usual way things work within macports when a port is upgraded, but let me run a check to see if in this case the presence of this include area from the 13.2 build is interfering in some way.

so unfortunately this did not help...

[cjones051073]

from the SDK I am using (15.4) . can you compare it to what you have with 15.3 to see what has changed ? math.h.gz

Now I am very confused - that file is the same as the one in the SDK I am using - and which [as per the comment above] built and tested fine from my branch. I'm now doing a build with clang as the bootstrap compiler (so no Ada or D).

For the record, my bootstrap using clang also worked fine - so it's puzzling - almost as if the starting tarball was somehow corrupted - as FX says, the patch that fixed the issue should already have been in that.

the source tree we are building is precisely the same as this tag https://github.com/iains/gcc-13-branch/releases/tag/gcc-13.3-darwin-r0

OK; so we have to figure out where the difference is coming from, since that builds fine for me on macOS14.5 with either GCC or clang as the bootstrap compiler.

Are you able to look at gcc/include-fixed in the failed build tree? (you might need to look at gcc-prev/include-fixed if you fail in stage2+

if you manually run make in the failed directory and then get the failed compile line; we can then do things like adding -H to print out the header searches as they happen - that should tell you where the math.h is coming from.

So after the build fails this is all I find

Larissa /opt/local/var/macports/build/_Users_chris_Projects_MacPorts_ports_lang_gcc13/libgcc13/work/build > find . -name include-fixed
./prev-gcc/include-fixed

and that dir only contains a README

Larissa /opt/local/var/macports/build/_Users_chris_Projects_MacPorts_ports_lang_gcc13/libgcc13/work/build/prev-gcc/include-fixed > ls
README
Larissa /opt/local/var/macports/build/_Users_chris_Projects_MacPorts_ports_lang_gcc13/libgcc13/work/build/prev-gcc/include-fixed > cat README 
This README file is copied into the directory for GCC-only header files
when fixincludes is run by the makefile for GCC.

Many of the files in this directory were automatically edited from the
standard system header files by the fixincludes process.  They are
system-specific, and will not work on any other kind of system.  They
are also not part of GCC.  The reason we have to do this is because
GCC requires ANSI C headers and many vendors supply ANSI-incompatible
headers.

Because this is an automated process, sometimes headers get "fixed"
that do not, strictly speaking, need a fix.  As long as nothing is broken
by the process, it is just an unfortunate collateral inconvenience.
We would like to rectify it, if it is not "too inconvenient".

[cjones051073]

I presume the lack of any headers there is not correct ?

[iains]

I presume the lack of any headers there is not correct ?

indeed .. it is not - this is from my build:

$ ls -F gcc/include-fixed/
README          dispatch/       math.h          objc/           os/             stdint.h        stdio.h

... if you were using --with-build-sysroot= I could understand this .. but it's not at al clear what's happening - if the build thinks that there are no headers to fix ..

[cjones051073]

I presume the lack of any headers there is not correct ?

indeed .. it is not - this is from my build:

$ ls -F gcc/include-fixed/
README          dispatch/       math.h          objc/           os/             stdint.h        stdio.h

Can you see enough from the log to tell why the build is failing to create these ? Or is there anything you want me to do to check ? I have the src area and build area at the point it failed.

[iains]

right this moment I need to concentrate on $dayjob .. so will have to look later; I'd maybe suggest trying make fixincludes and see if there's some error .. and/or make install-fixincludes and see if they are being put somewhere bizarre?

[cjones051073]

make install-fixincludes

Larissa /opt/local/var/macports/build/_Users_chris_Projects_MacPorts_ports_lang_gcc13/libgcc13/work/build > sudo make fixincludes
Password:
make: Nothing to be done for `fixincludes'.
Larissa /opt/local/var/macports/build/_Users_chris_Projects_MacPorts_ports_lang_gcc13/libgcc13/work/build > sudo make install-fixincludes
/bin/sh /opt/local/var/macports/build/_Users_chris_Projects_MacPorts_ports_lang_gcc13/libgcc13/work/gcc-13.3.0/mkinstalldirs /opt/local /opt/local
make[1]: *** No rule to make target `install'.  Stop.
make: *** [install-fixincludes] Error 2

that last one looks suspicious to me. Note the /opt/local is the primary MacPorts install prefix, and nothing during the builds should be trying to write there - they infact will not have any access. This area is only populated at the very end of the build, once the DESTROOT install has been completed and we finally install the end product.

[iains]

make install-fixincludes

Larissa /opt/local/var/macports/build/_Users_chris_Projects_MacPorts_ports_lang_gcc13/libgcc13/work/build > sudo make fixincludes
Password:
make: Nothing to be done for `fixincludes'.
Larissa /opt/local/var/macports/build/_Users_chris_Projects_MacPorts_ports_lang_gcc13/libgcc13/work/build > sudo make install-fixincludes
/bin/sh /opt/local/var/macports/build/_Users_chris_Projects_MacPorts_ports_lang_gcc13/libgcc13/work/gcc-13.3.0/mkinstalldirs /opt/local /opt/local
make[1]: *** No rule to make target `install'.  Stop.
make: *** [install-fixincludes] Error 2

that last one looks suspicious to me. Note the /opt/local is the primary MacPorts install prefix, and nothing during the builds should be trying to write there - they infact will not have any access. This area is only populated at the very end of the build, once the DESTROOT install has been completed and we finally install the end product.

this is my output (but you should also look for where the fixed includes get installed into the build gcc directory):

$ make install-fixincludes
/bin/sh /src-local/gcc-git-13/mkinstalldirs /opt/iains/aarch64-apple-darwin23/gcc-13-3Dr1 /opt/iains/aarch64-apple-darwin23/gcc-13-3Dr1
make[1]: Entering directory '/scratch/14-son/gcc-13/fixincludes'
rm -rf /opt/iains/aarch64-apple-darwin23/gcc-13-3Dr1/libexec/gcc/aarch64-apple-darwin23/13.3.0/install-tools
/bin/sh /src-local/gcc-git-13/fixincludes/../mkinstalldirs /opt/iains/aarch64-apple-darwin23/gcc-13-3Dr1/libexec/gcc/aarch64-apple-darwin23/13.3.0/install-tools
mkdir /opt/iains/aarch64-apple-darwin23/gcc-13-3Dr1/libexec/gcc/aarch64-apple-darwin23/13.3.0/install-tools
/bin/sh /src-local/gcc-git-13/fixincludes/../mkinstalldirs /opt/iains/aarch64-apple-darwin23/gcc-13-3Dr1/lib/gcc/aarch64-apple-darwin23/13.3.0/install-tools/include
/usr/bin/install -c -m 644 /src-local/gcc-git-13/fixincludes/README-fixinc \
  /opt/iains/aarch64-apple-darwin23/gcc-13-3Dr1/lib/gcc/aarch64-apple-darwin23/13.3.0/install-tools/include/README
/usr/bin/install -c fixinc.sh /opt/iains/aarch64-apple-darwin23/gcc-13-3Dr1/libexec/gcc/aarch64-apple-darwin23/13.3.0/install-tools/fixinc.sh
/usr/bin/install -c fixincl /opt/iains/aarch64-apple-darwin23/gcc-13-3Dr1/libexec/gcc/aarch64-apple-darwin23/13.3.0/install-tools/fixincl
/usr/bin/install -c mkheaders /opt/iains/aarch64-apple-darwin23/gcc-13-3Dr1/libexec/gcc/aarch64-apple-darwin23/13.3.0/install-tools/mkheaders
make[1]: Leaving directory '/scratch/14-son/gcc-13/fixincludes'

[iains]

so in your build you should see something like:

    /bin/sh /src-local/gcc-git-13/gcc/../mkinstalldirs ${fix_dir}; \
    chmod a+rx ${fix_dir} || true; \
    (TARGET_MACHINE='aarch64-apple-darwin23'; srcdir=`cd /src-local/gcc-git-13/gcc; ${PWDCMD-pwd}`; \
      SHELL='/bin/sh'; MACRO_LIST=`${PWDCMD-pwd}`/macro_list ; \
      gcc_dir=`${PWDCMD-pwd}` ; \
      export TARGET_MACHINE srcdir SHELL MACRO_LIST && \
      cd ../build-aarch64-apple-darwin23/fixincludes && \
      /bin/sh ./fixinc.sh "${gcc_dir}/${fix_dir}" \
        `echo /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk${sysroot_headers_suffix}/usr/include | sed -e :a -e 's,[^/]*/\.\.\/,,' -e ta`  ); \
  done; \
fi
Fixing headers into /scratch/14-son/gcc-13/gcc/include-fixed for aarch64-apple-darwin23 target
No forbidden identifiers defined by this target
Finding directories and links to directories
 Searching /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/.
 Searching /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/./libxml2/libxml
Making symbolic directory links
Fixing directory /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include into /scratch/14-son/gcc-13/gcc/include-fixed
Applying ctrl_quotes_def          to editline/readline.h
Applying io_quotes_def            to c++/v1/__type_traits/aligned_storage.h
Applying io_quotes_def            to net/if_media.h
Applying io_quotes_def            to unicode/platform.h
Applying io_quotes_use            to security/audit/audit_ioctl.h
Applying io_quotes_def            to net-snmp/library/container.h
Applying darwin_dispatch_object_1 to dispatch/object.h
...

I'll try and take a look later...

[cjones051073]

Is this the problem ?

Fixing headers into /opt/local/var/macports/build/_Users_chris_Projects_MacPorts_ports_lang_gcc13/libgcc13/work/build/gcc/include-fixed for aarch64-apple-darwin23 target
No forbidden identifiers defined by this target
Finding directories and links to directories
 Searching /opt/local/include/gcc/.

It appears the fixincludes is running against the wrong area, /opt/local/include/gcc instead of the SDK being used /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk ?

[cjones051073]

I suspect this is related to our use in MacPorts of the configuration option --includedir=/opt/local/include/gcc We have, historically, always used this to tell GCC where to take its own headers from, but it seems (either because we have always been mis-using this option or something has changed) this is now used to define where the 'system' headers come from, and setting this is causing bad side effects like this.

[cjones051073]

OK so removing --includedir=/opt/local/include/gcc has indeed fixed the build issue.

I need to let the full builds complete and then assess what impact removing our use of this has on the way we package the GCC versions we distribution within MacPorts, as our packaging there is a bit specialised in a few ways. If though GCC is no longer using this option in the same way as it was when we first starting using it, which seems the case the more I look at it, it might well be just removing it at this point is fine. But I need to check a few things first.

[barracuda156]

@iains FWIW, I have built gcc 13.3.0 on 10.6 powerpc without any issues (without removing --includedir=). But I did get the same error from @cjones051073 portfile on 14.5 with Xcode 15.4.

[barracuda156]

OK so removing --includedir=/opt/local/include/gcc has indeed fixed the build issue.

I need to let the full builds complete and then assess what impact removing our use of this has on the way we package the GCC versions we distribution within MacPorts, as our packaging there is a bit specialised in a few ways. If though GCC is no longer using this option in the same way as it was when we first starting using it, which seems the case the more I look at it, it might well be just removing it at this point is fine. But I need to check a few things first.

@cjones051073 We probably need to verify it works the same when bootstrap it done with gcc instead of clang. The breakage can be clang-specific.