clang-17 build fails on Sequoia

[jwhowarth]

In attempting to install apbs, I discovered that the clang-17 build fails as follows...

/Library/Developer/CommandLineTools/usr/bin/clang -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -DL_cas -DMODEL=2 -DSIZE=1 -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_llvm-17/clang-17/work/llvm-project-17.0.6.src/compiler-rt/lib/builtins -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_llvm-17/clang-17/work/build/projects/compiler-rt/lib/builtins -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_llvm-17/clang-17/work/llvm-project-17.0.6.src/compiler-rt/lib/builtins -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_llvm-17/clang-17/work/build/include -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_llvm-17/clang-17/work/llvm-project-17.0.6.src/llvm/include -O3 -DNDEBUG -arch arm64 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX15.sdk -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk -mmacosx-version-min=10.7 -fPIC -O3 -fvisibility=hidden -DVISIBILITY_HIDDEN -Wall -fomit-frame-pointer -DHAS_ASM_LSE -Werror=format-nonliteral -DDONT_DEFINE_EPRINTF -arch arm64 -target arm64-apple-macos10.7 -darwin-target-variant arm64-apple-ios13.1-macabi -MD -MT projects/compiler-rt/lib/builtins/CMakeFiles/clang_rt.builtins_arm64_osx.dir/outline_atomic_helpers.dir/outline_atomic_cas1_2.S.o -MF projects/compiler-rt/lib/builtins/CMakeFiles/clang_rt.builtins_arm64_osx.dir/outline_atomic_helpers.dir/outline_atomic_cas1_2.S.o.d -o projects/compiler-rt/lib/builtins/CMakeFiles/clang_rt.builtins_arm64_osx.dir/outline_atomic_helpers.dir/outline_atomic_cas1_2.S.o -c /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_llvm-17/clang-17/work/build/projects/compiler-rt/lib/builtins/outline_atomic_helpers.dir/outline_atomic_cas1_2.S
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_llvm-17/clang-17/work/build/projects/compiler-rt/lib/builtins/outline_atomic_helpers.dir/outline_atomic_cas1_2.S:145:116: error: non-private labels cannot appear between .cfi_startproc / .cfi_endproc pairs
 .text %% .balign 16 %% .globl __aarch64_cas1_acq %% %% .private_extern __aarch64_cas1_acq %% %% .cfi_startproc %% __aarch64_cas1_acq: %%
                                                                                                                   ^
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_llvm-17/clang-17/work/build/projects/compiler-rt/lib/builtins/outline_atomic_helpers.dir/outline_atomic_cas1_2.S:145:98: error: previous .cfi_startproc was here
 .text %% .balign 16 %% .globl __aarch64_cas1_acq %% %% .private_extern __aarch64_cas1_acq %% %% .cfi_startproc %% __aarch64_cas1_acq: %%

The clang-18 build doesn't have this problem.

[cjones051073 (Chris Jones)]

Please attach a complete build log from a clean build attempt of clang-17

[ryandesign (Ryan Carsten Schmidt)]

See also #70710 for the same error affecting gcc-13.

[cjones051073 (Chris Jones)]

See [8e4cf778021470a4f5cd2adc5566d43f79f56baf/macports-ports]

that limits clang fallback on macOS15+ to clang-18 (or newer once clang-19 is added).

If clang-17 is ever fixed for macOS15+ this can be reviewed.

[jwhowarth]

FYI, so far the only sensible commit that I've identified in llvm 18.x to back port to llvm 17.0.6 is this one.

Reland "[MC][AsmParser] Diagnose improperly nested .cfi frames" This showed up when simplifying some large testcase, where the cfi directives became out of sync with the proc's they enclose.

Now restricted to platforms that support .subsections_via_symbols.

This reverts commit 797b68c.

Fixes: #72802

Differential revision: ​https://reviews.llvm.org/D153167

rdar://111459507

​https://github.com/llvm/llvm-project/commit/d506aa4edfa66074db3dc1fa84da9d9c80d71500

Unfortunately, this change alone appears to be insufficient to eliminate the build failures on Sequoia.

[cjones051073 (Chris Jones)]

Unless upstream fixes LLVM 17 themselves I think we should just limit clang on macOS15 on our side to clang-18 or newer, which work fine. There should be no need to *require* clang-17 really.

[markemer (Mark Anderson)]

Yeah - if clang 18 and 19 build and work, I'm ok with just limiting clang on macOS 15+

I assume nothing (or almost nothing) that requires 17 won't build with 18/19?

[markemer (Mark Anderson)]

Replying to jwhowarth:

FYI, so far the only sensible commit that I've identified in llvm 18.x to back port to llvm 17.0.6 is this one.

Reland "[MC][AsmParser] Diagnose improperly nested .cfi frames" This showed up when simplifying some large testcase, where the cfi directives became out of sync with the proc's they enclose.

Now restricted to platforms that support .subsections_via_symbols.

This reverts commit 797b68c.

Fixes: #72802

Differential revision: ​https://reviews.llvm.org/D153167

rdar://111459507

​https://github.com/llvm/llvm-project/commit/d506aa4edfa66074db3dc1fa84da9d9c80d71500

Unfortunately, this change alone appears to be insufficient to eliminate the build failures on Sequoia.

Maybe the error is in the Xcode compiler? Could we try compiling with one of ours. Like clang18 from MP?

[cjones051073 (Chris Jones)]

Replying to markemer:

Replying to jwhowarth:

FYI, so far the only sensible commit that I've identified in llvm 18.x to back port to llvm 17.0.6 is this one.

Reland "[MC][AsmParser] Diagnose improperly nested .cfi frames" This showed up when simplifying some large testcase, where the cfi directives became out of sync with the proc's they enclose.

Now restricted to platforms that support .subsections_via_symbols.

This reverts commit 797b68c.

Fixes: #72802

Differential revision: ​https://reviews.llvm.org/D153167

rdar://111459507

​https://github.com/llvm/llvm-project/commit/d506aa4edfa66074db3dc1fa84da9d9c80d71500

Unfortunately, this change alone appears to be insufficient to eliminate the build failures on Sequoia.

Maybe the error is in the Xcode compiler? Could we try compiling with one of ours. Like clang18 from MP?

anyone who wishes to can try that for themselves.

 > sudo port install clang-17 configure.compiler=macports-clang-18

[markemer (Mark Anderson)]

Neat trick. Trying it. Will report back.

[markemer (Mark Anderson)]

Sadly, no that fails - it's annoying that this is not really a valid error - but I don't see a good way of fixing it in clang-17

[markmentovai (Mark Mentovai)]

Replying to markemer:

Sadly, no that fails - it's annoying that this is not really a valid error - but I don't see a good way of fixing it in clang-17

A straightforward cherry-pick of ​llvm 7939ce39dac0 to release/17.x is all that’s needed. That change is trivial and not incorrect in any circumstance. It applies cleanly as far back as llvm-13, which should be enough for MacPorts, which has already dropped ≤ llvm-14 on ≥ macOS 14 (​MacPorts 0c2af4734924).

I can send a pull request if that’d be helpful, but in light of comment:7, I’m not sure it’s worth the time.

[cjones051073 (Chris Jones)]

If the patch needed is indeed that simple the I think its worth trying…

[cjones051073 (Chris Jones)]

Running a test for clang-17 on macOS15 arm64 ...

[cjones051073 (Chris Jones)]

Seems to have worked ! clang-17 built fine and passes a few test builds I threw at it.

Will tests updates to a few more clang versions before pushing an update.

[markmentovai (Mark Mentovai)]

I just prepared ​https://github.com/macports/macports-ports/pull/25912 for this and was going to do it back to clang-14.

[cjones051073 (Chris Jones)]

OK thanks, if you can add the other clangs there we can go with your PR.

[markmentovai (Mark Mentovai)]

llvm-14, at least, will require more than just this fix, for the same issue in other assembler source.

What do you prefer?

• Don’t touch a version if it’s not being fixed fully
• Apply the (still correct) fix from ​llvm-project 7939ce39dac0, but leave the ports marked broken on darwin-24 if more fixes will be needed in the future
• Wait until we have a fix for everything

[markmentovai (Mark Mentovai)]

• clang-17: ​#25912
• clang-16: ​#25917
• clang-15: ​#25918
• clang-14: ​#25919

[markmentovai (Mark Mentovai)]

In 006dc9abc2af6435281d0be246336a82cafb5985/macports-ports (master):

clang-17, llvm-17: restore functionality on macOS 15 (Xcode 16)

This is a cherry-pick of
​https://github.com/llvm/llvm-project/commit/7939ce39dac0078fef7183d6198598b99c652c88.

This enables clang-17 to be built by Xcode 16, making it possible to
build on macOS 15, and macOS 14 with Xcode 16. It also enables clang-17
to be built by clang-18 and newer.

Closes: #70779

[markmentovai (Mark Mentovai)]

For ​llvm-14, ​llvm-15, and ​llvm-16, there was an additional problem building the lldb-14, lldb-15, and lldb-16 subports. The lldb problem occurred with the macOS 14 SDK, so it’s somewhat long-standing, but I didn’t find any reports on file about it, so I’ll just deal with it here.

I’ve updated each of the pull requests for those versions to include an additional commit to fix lldb.

[markmentovai (Mark Mentovai)]

In 52d765130d2408c89acac93899a914af855a98e2/macports-ports (master):

lldb-16: fix build with macOS ≥ 14 SDK (Xcode ≥ 15)

This is a cherry-pick of
​https://github.com/llvm/llvm-project/commit/73e15b5edb4fa4a77e68c299a6e3b21e610d351f.

This enables lldb-16 to be built by Xcode ≥ 15, making it possible to
build on macOS ≥ 14, and macOS 13 with Xcode 15.

References: #70779

[markmentovai (Mark Mentovai)]

In 59bca6e0cf49381a74690e99e4ef59739714c3f7/macports-ports (master):

clang-16, llvm-16: restore functionality on macOS 15 (Xcode 16)

This is a cherry-pick of:
​https://github.com/llvm/llvm-project/commit/c57c7b7c99605021123b54c02e57943923874cbe
​https://github.com/llvm/llvm-project/commit/7939ce39dac0078fef7183d6198598b99c652c88

This enables clang-16 to be built by Xcode 16, making it possible to
build on macOS 15, and macOS 14 with Xcode 16. It also enables clang-16
to be built by clang-18 and newer.

References: #70779

[markmentovai (Mark Mentovai)]

In 6f1c0b562ad9ef5919cfa5755b51a9aebfed71d6/macports-ports (master):

lldb-15: fix build with macOS ≥ 14 SDK (Xcode ≥ 15)

This is a cherry-pick of
​https://github.com/llvm/llvm-project/commit/73e15b5edb4fa4a77e68c299a6e3b21e610d351f.

This enables lldb-15 to be built by Xcode ≥ 15, making it possible to
build on macOS ≥ 14, and macOS 13 with Xcode 15.

References: #70779

[markmentovai (Mark Mentovai)]

In 70088c9cf4ce312082ecf721d7a4776df8b1eca7/macports-ports (master):

clang-15: Move libc++*.* libraries to libc++ sub-dir, fix install names

This applies a1d4865220b5, which addressed this for clang-16–18 for
#68640, to clang-15, to fix a bug
observed while running clang-15 as a linker driver on macOS 15.

When running as a linker driver, clang provides ld with clang’s own LTO
plugin by invoking ld with `-lto_library
${PREFIX}/libexec/llvm-15/lib/libLTO.dylib`. Upon receipt of these
arguments, Xcode ld currently loads the plugin by re-execveing itself
with DYLD_LIBRARY_PATH=${PREFIX}/libexec/llvm-15/lib in effect, causing
dyld to prefer libLTO.dylib in that directory over the
@rpath/libLTO.dylib that ld requests to load via a Mach-O load command.
With DYLD_LIBRARY_PATH in effect, dyld can potentially use any other
module in that same directory to satisfy any other Mach-O load command.
In this case, the directory contained both libc++.dylib and
libc++abi.dylib from clang, and dyld used these to replace the libraries
of the same name ordinarily provided by the OS in /usr/lib (via the dyld
shared cache). This is undesirable in general, but occurred silently on
macOS < 15. It became noticeable on macOS 15 because system libraries
that depend on libc++abi.dylib now reference symbols that are present in
the system’s version, but not in clang’s, causing messages such as

dyld[60301]: symbol 'ZnwmSt19type_descriptor_t' missing from root that overrides /usr/lib/libc++abi.dylib. Use of that symbol in /usr/lib/swift/libswiftCore.dylib is being set to 0xBAD4007.
dyld[60301]: symbol 'ZdlPvSt19type_descriptor_t' missing from root that overrides /usr/lib/libc++abi.dylib. Use of that symbol in /usr/lib/swift/libswiftCore.dylib is being set to 0xBAD4007.

repeated for every system library that references those symbols. These
messages warn of potential run-time bugs due to dyld intentionally
mis-resolving the missing symbols.

As clang should not seek to replace the system’s libc++ with its own in
system libraries, this was a latent problem even pre-macOS 15.

The workaround moves clang’s libc++ libraries to a new subdirectory,
${PREFIX}/libexec/llvm-15/lib/libc++, where they will not be found or
used even with DYLD_LIBRARY_PATH set to ${PREFIX}/libexec/llvm-15/lib as
it is when clang runs the linker.

This also contains a fix for the LC_INSTALL_NAMEs of libc++.dylib and
libc++abi.dylib, which should have been recorded as @rpath-relative, but
due to an error in the Portfile’s handling of CMAKE_INSTALL_NAME_DIR,
were instead recorded using absolute paths rooted at
${PREFIX}/libexec/llvm-15/lib. When the libraries were moved elsewhere,
they tripped MacPorts’ check for linking errors due to libc++.dylib’s
dependency on libc++abi.dylib at a path where it was no longer
installed. Discussion at
​https://github.com/macports/macports-ports/pull/25918#issuecomment-2377971503.

This is an observable change in the installed clang-15 package, but the
revision is not being bumped in this commit because this change is being
merged atomically in ​https://github.com/macports/macports-ports/pull/25918 with another change that updates clang-15’s
revision.

References: #70779

[markmentovai (Mark Mentovai)]

In 4c231f2e9d0dd9223c96d849bea8b5b1d903b571/macports-ports (master):

clang-15, llvm-15: restore functionality on macOS 15 (Xcode 16)

This is a cherry-pick of:
​https://github.com/llvm/llvm-project/commit/c57c7b7c99605021123b54c02e57943923874cbe
​https://github.com/llvm/llvm-project/commit/7939ce39dac0078fef7183d6198598b99c652c88

This enables clang-15 to be built by Xcode 16, making it possible to
build on macOS 15, and macOS 14 with Xcode 16. It also enables clang-15
to be built by clang-18 and newer.

References: #70779

[markmentovai (Mark Mentovai)]

In e8938c3ebf0ed4210a94740ee8a63195ed0fc9fb/macports-ports (master):

lldb-14: fix build with macOS ≥ 14 SDK (Xcode ≥ 15)

This is a cherry-pick of
​https://github.com/llvm/llvm-project/commit/73e15b5edb4fa4a77e68c299a6e3b21e610d351f.

This enables lldb-14 to be built by Xcode ≥ 15, making it possible to
build on macOS ≥ 14, and macOS 13 with Xcode 15.

References: #70779

[markmentovai (Mark Mentovai)]

In aa0bc47391a7b7ebee3de8e1cb2911d73d14d2ec/macports-ports (master):

clang-14: Move libc++*.* libraries to libc++ sub-dir, fix install names

This applies a1d4865220b5, which addressed this for clang-16–18 for
#68640, to clang-14, to fix a bug
observed while running clang-14 as a linker driver on macOS 15.

When running as a linker driver, clang provides ld with clang’s own LTO
plugin by invoking ld with `-lto_library
${PREFIX}/libexec/llvm-14/lib/libLTO.dylib`. Upon receipt of these
arguments, Xcode ld currently loads the plugin by re-execveing itself
with DYLD_LIBRARY_PATH=${PREFIX}/libexec/llvm-14/lib in effect, causing
dyld to prefer libLTO.dylib in that directory over the
@rpath/libLTO.dylib that ld requests to load via a Mach-O load command.
With DYLD_LIBRARY_PATH in effect, dyld can potentially use any other
module in that same directory to satisfy any other Mach-O load command.
In this case, the directory contained both libc++.dylib and
libc++abi.dylib from clang, and dyld used these to replace the libraries
of the same name ordinarily provided by the OS in /usr/lib (via the dyld
shared cache). This is undesirable in general, but occurred silently on
macOS < 15. It became noticeable on macOS 15 because system libraries
that depend on libc++abi.dylib now reference symbols that are present in
the system’s version, but not in clang’s, causing messages such as

dyld[60301]: symbol 'ZnwmSt19type_descriptor_t' missing from root that overrides /usr/lib/libc++abi.dylib. Use of that symbol in /usr/lib/swift/libswiftCore.dylib is being set to 0xBAD4007.
dyld[60301]: symbol 'ZdlPvSt19type_descriptor_t' missing from root that overrides /usr/lib/libc++abi.dylib. Use of that symbol in /usr/lib/swift/libswiftCore.dylib is being set to 0xBAD4007.

repeated for every system library that references those symbols. These
messages warn of potential run-time bugs due to dyld intentionally
mis-resolving the missing symbols.

As clang should not seek to replace the system’s libc++ with its own in
system libraries, this was a latent problem even pre-macOS 15.

The workaround moves clang’s libc++ libraries to a new subdirectory,
${PREFIX}/libexec/llvm-14/lib/libc++, where they will not be found or
used even with DYLD_LIBRARY_PATH set to ${PREFIX}/libexec/llvm-14/lib as
it is when clang runs the linker.

This also contains a fix for the LC_INSTALL_NAMEs of libc++.dylib and
libc++abi.dylib, which should have been recorded as @rpath-relative, but
due to an error in the Portfile’s handling of CMAKE_INSTALL_NAME_DIR,
were instead recorded using absolute paths rooted at
${PREFIX}/libexec/llvm-14/lib. When the libraries were moved elsewhere,
they tripped MacPorts’ check for linking errors due to libc++.dylib’s
dependency on libc++abi.dylib at a path where it was no longer
installed. Discussion at
​https://github.com/macports/macports-ports/pull/25918#issuecomment-2377971503.

This is an observable change in the installed clang-14 package, but the
revision is not being bumped in this commit because this change is being
merged atomically in ​https://github.com/macports/macports-ports/pull/25919 with another change that updates clang-14’s
revision.

References: #70779

[markmentovai (Mark Mentovai)]

In f1724d202cb5ad6331b6265545ccd0ef8d43e3de/macports-ports (master):

clang-14, llvm-14: restore functionality on macOS 15 (Xcode 16)

This is a cherry-pick of:
​https://github.com/llvm/llvm-project/commit/c57c7b7c99605021123b54c02e57943923874cbe
​https://github.com/llvm/llvm-project/commit/7939ce39dac0078fef7183d6198598b99c652c88

This enables clang-14 to be built by Xcode 16, making it possible to
build on macOS 15, and macOS 14 with Xcode 16. It also enables clang-14
to be built by clang-18 and newer.

References: #70779

[markmentovai (Mark Mentovai)]

In 9e855c03657030f7cc3c85a41a89e09ae453be67/macports-ports (master):

clang-13, llvm-13, lldb-13: fix for macOS ≥ 14

This rolls up backports of the following fixes for later llvm versions
to llvm-13:

93df94134805 clang-14: Fix build under Xcode 15
2605e66ff779 lldb-14: fix build with macOS ≥ 14 SDK (Xcode ≥ 15)
aa0bc47391a7 clang-14: Move libc++*.* libraries to libc++ sub-dir, fix

install names

49df5ce7f1f6 clang-14, llvm-14: restore functionality on macOS 15 (Xcode

16)

References: #68257
References: #70779

[markmentovai (Mark Mentovai)]

In 2981eb25d2ca139de4ada36872cb19886d8e2ec3/macports-ports (master):

clang-12, llvm-12, lldb-12: fix for macOS ≥ 14 (​https://github.com/macports/macports-ports/pull/26025)

This rolls up backports of the following fixes for later llvm versions
to llvm-12:

93df94134805 clang-14: Fix build under Xcode 15
2605e66ff779 lldb-14: fix build with macOS ≥ 14 SDK (Xcode ≥ 15)
aa0bc47391a7 clang-14: Move libc++*.* libraries to libc++ sub-dir, fix

install names

49df5ce7f1f6 clang-14, llvm-14: restore functionality on macOS 15 (Xcode

16)

It also enables lldb-12 on macOS ≥ 14, where it was previously
separately disabled.

References: #68257
References: #70779