libgcc14 @14.1.0_0+stdlib_flag: Can't build against 11.3 SDK on macOS 14

[lukaso (Lukas Oberhuber)]

Build error when building against 11.3 SDK. This has only turned up recently when libgcc was switched from gcc 13 to gcc 14 (I believe).

:info:build /Users/circleci/macports-gimp3-x86_64/var/macports/build/_Users_circleci_macports-gimp3-x86_64_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc14/libgcc14/work/build/gcc/include-fixed/AvailabilityInternal.h:185:10: fatal error: AvailabilityInternalLegacy.h: No such file or directory
:info:build   185 | #include <AvailabilityInternalLegacy.h>
:info:build       |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Setup with:

  echo 'macosx_deployment_target 11.0' | tee -a ${PREFIX}/etc/macports/macports.conf
  echo 'macosx_sdk_version 11.3' | tee -a ${PREFIX}/etc/macports/macports.conf

And

export SDKROOT=/Library/Developer/CommandLineTools/SDKs/MacOSX11.3.sdk

[cjones051073 (Chris Jones)]

Hmm, not really a commonly used or well supported configuration, to build for an older OS than the one you are running.

[cjones051073 (Chris Jones)]

Note gcc14 builds just fine against the 11 SDK, see the macOS11 builds at

​https://ports.macports.org/port/libgcc14/details/

So your configuration changes are in some way the cause of the problem.

[ryandesign (Ryan Carsten Schmidt)]

Maybe you could attach the file build/gcc/include-fixed/AvailabilityInternal.h so that we can see what's wrong with it.

[cjones051073 (Chris Jones)]

FWIW in the latest GCC 13 update, and the new GCC14 port some changes where made to the gcc configuration as discussed in

​https://github.com/iains/gcc-13-branch/issues/20

the changes there specifically fix an issue with how the 'fixincludes' are generated by GCC, so I suspect what we are seeing here is a consequence of that, that those fixes have probably exposed an issue with how you are attempting to target an older OS that for whatever reason is not working with the new configuration.

I am afraid but I think you will need to discuss this with Iain himself, as I do not know anything about targeting older deployment targets myself with GCC.

[lukaso (Lukas Oberhuber)]

The file that is causing the problem.

[lukaso (Lukas Oberhuber)]

Maybe you could attach the file build/gcc/include-fixed/AvailabilityInternal.h so that we can see what's wrong with it.

Done.

I checked the MacOS 14 SDK (sonoma) and the missing file is there, so it's a difference between the two SDKs.

And I'll look into the issue above when I get the chance.

[lukaso (Lukas Oberhuber)]

Good call on checking AvailabilityInternal.h. Looks like it's ignoring the SDKROOT setting.

This is at the top:

/*  DO NOT EDIT THIS FILE.

    It has been auto-edited by fixincludes from:

	"/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/AvailabilityInternal.h"

    This had to be done to correct non-standard usages in the
    original, manufacturer supplied header file.  */

But SDKROOT is set to SDKROOT='/Library/Developer/CommandLineTools/SDKs/MacOSX11.3.sdk'

[lukaso (Lukas Oberhuber)]

OK, I've logged a bug upstream as well: ​https://github.com/iains/gcc-14-branch/issues/6

[cjones051073 (Chris Jones)]

See my last comments to that GitHub issue.

Bottom line is this is currently intentional. the gcc build intentionally strips the versions from from the SDK in order to favour the generic versio less one. See

​https://github.com/macports/macports-ports/blob/169504d70ab969c160518b462421ee5ca4c99642/lang/gcc14/Portfile#L86

[cjones051073 (Chris Jones)]

In case you are wondering why this was done, it was to avoid problems with the more rapidly varying SDK versions that started with macOS11

What I suggest you try is instead of setting the minor version of the SDK, as you do above, instead set it to just 11. By not setting the minor version, which the gcc build rejects, it should respect the setting.

[cjones051073 (Chris Jones)]

A fix to the portfile we could consider, if the above works for you, is if a minor version SDK is detected, instead of removing all version information, only strip the minor version, and retain the major. If you can confirm the above works then its something I can look into doing.

[Chris Jones <jonesc@…>]

In 48f30ded111c465364f30a85c57876b447529fdb/macports-ports (master):

gcc{11,12,13}: Retain SDK major version when cleaning SDKROOT

See: #70328

[cjones051073 (Chris Jones)]

Lukas please test the above.

[lukaso (Lukas Oberhuber)]

I'm trying to do that right now, however I've now run into a problem with llvm-18: #70333 so now I'm blocked behind that.

[cjones051073 (Chris Jones)]

LLVM issue now fixed. Please make sure you get the latest updates including [bcfb793f4fecbc1af973d85e057141637450b25c/macports-ports]

[lukaso (Lukas Oberhuber)]

Seems like it takes a while for the tarball to update. Instead I edited myself (for now)

[cjones051073 (Chris Jones)]

I recommend switching to a direct github checkout of the ports tree. There is then no delay on getting updates…

[ryandesign (Ryan Carsten Schmidt)]

Replying to lukaso:

Seems like it takes a while for the tarball to update.

Plan on it taking about an hour.

[lukaso (Lukas Oberhuber)]

OK, the only way I was able to get libgcc14 to build was to change the code in the gcc14/Portfile to:

proc get_clean_sysroot {} {
    global configure.sdkroot
    return ${configure.sdkroot}
}

I'm not a tcl person so not sure why changing SDKROOT to .../MacOS11.sdk for the build didn't work, but it didn't.

[cjones051073 (Chris Jones)]

You need to provide clean logs showing the problem…..

[cjones051073 (Chris Jones)]

In particular i need to see what the two debug statements at

​https://github.com/macports/macports-ports/blob/cb7146516bcdb4d836680720ce09226adc3d63b3/lang/gcc14/Portfile#L91

Are printing.

[cjones051073 (Chris Jones)]

b.t.w. I assume you actually have a MacOSX11.sdk ? I assumed you would check this first but perhaps not.

It should be a symbolic link to the fully versioned SDK, e.g.

Larissa ~/Projects/MacPorts/ports > ls -lt /Library/Developer/CommandLineTools/SDKs 
total 0
lrwxr-xr-x  1 root  wheel   14  1 Jul 20:46 MacOSX.sdk -> MacOSX14.4.sdk
lrwxr-xr-x  1 root  wheel   14  1 Jul 20:46 MacOSX13.sdk -> MacOSX13.3.sdk
lrwxr-xr-x  1 root  wheel   14  1 Jul 20:45 MacOSX14.sdk -> MacOSX14.4.sdk
drwxr-xr-x  7 root  wheel  224 20 Feb 00:28 MacOSX14.4.sdk
drwxr-xr-x  7 root  wheel  224 12 May  2023 MacOSX13.3.sdk

I don't know how you got your MacOSX11 SDK on macOS14, but perhaps you did not fully install it correctly and you are missing the equivalent sym links above for it. If so fix this and try again.

[lukaso (Lukas Oberhuber)]

I don't know how you got your MacOSX11 SDK on macOS14, but perhaps you did not fully install it correctly and you are missing the equivalent sym links above for it. If so fix this and try again.

Yeah, I fixed that, but it just went to the standard sdk.

My workaround for now: overlay the port with the function above because I've run out of time.

I'll hopefully have time this weekend.

Separately: what is the benefit of special casing the SDKs?

This was done January 2021 for gcc 8, 9 and 10: ​https://github.com/macports/macports-ports/commit/e8866c5019d60832527850b4e50fdc1de8878716 by @kencu.

But other than stating the SDKs change rapidly, there isn't really a justification. I'm inferring it has something to do with building with an SDK and then baking in that SDK when building with gcc. Looks like there is some deep problem in gcc related to cross compiling. Looks like it's related to --with-sdkroot and --with-build-sdkroot or some such.

This is the linked bug(I haven't fully researched it): ​https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79885

I think it is supposed to make the gcc forward compatible.

Hope these ramblings help!

[cjones051073 (Chris Jones)]

When macOS 11 came out, so Apple finally moved away from 10.X for the major versions, a combination of what Apple was shipping at the time for its SDKs and what macports was doing with them meant the full MacOSX11.n.sdk was passed to the build. For ports like gcc that retains knowledge of the SDK used this causes issues if the SDK changes on a minor OS update, which at first it did. The cleaning in the gcc ports are to fix this, by removing the minor version.

Now since then, Apple has changed a bit how it ships its SDKs, providing these symlinks without the minor version. Macports has also improved how it handles things, so I think now unless a user does what you are doing here, forcing a particular minor versioned SDK the protection has no effect. So to that end I am going to retain it.

You keep mentioning you still have problems but are not providing the logs to back this up. Without these no one can help you. From my perspective the changes I have made address the issue here so unless you can prove otherwis, with full clean logs, I am going to close this.

[lukaso (Lukas Oberhuber)]

You keep mentioning you still have problems but are not providing the logs to back this up. Without these no one can help you. From my perspective the changes I have made address the issue here so unless you can prove otherwis, with full clean logs, I am going to close this.

Understood. As soon as I can, I'll provide.