Opened 3 months ago

Closed 3 months ago

Last modified 2 months ago

#70779 closed defect (fixed)

clang-17 build fails on Sequoia

Reported by: jwhowarth Owned by: markmentovai (Mark Mentovai)
Priority: Normal Milestone:
Component: ports Version: 2.10.1
Keywords: Cc: cjones051073 (Chris Jones), markmentovai (Mark Mentovai)
Port: clang-17

Description (last modified by ryandesign (Ryan Carsten Schmidt))

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.

Change History (33)

comment:1 Changed 3 months ago by jwhowarth

Description: modified (diff)

comment:2 Changed 3 months ago by cjones051073 (Chris Jones)

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

comment:3 Changed 3 months ago by cjones051073 (Chris Jones)

Cc: cjones051073 added

comment:4 Changed 3 months ago by ryandesign (Ryan Carsten Schmidt)

Description: modified (diff)

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

comment:5 Changed 3 months ago by 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.

Last edited 3 months ago by ryandesign (Ryan Carsten Schmidt) (previous) (diff)

comment:6 Changed 3 months ago by 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.

Last edited 3 months ago by ryandesign (Ryan Carsten Schmidt) (previous) (diff)

comment:7 Changed 3 months ago by 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.

comment:8 Changed 3 months ago by 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?

comment:9 in reply to:  6 ; Changed 3 months ago by 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?

Last edited 3 months ago by ryandesign (Ryan Carsten Schmidt) (previous) (diff)

comment:10 in reply to:  9 Changed 3 months ago by 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
Last edited 3 months ago by ryandesign (Ryan Carsten Schmidt) (previous) (diff)

comment:11 Changed 3 months ago by markemer (Mark Anderson)

Neat trick. Trying it. Will report back.

comment:12 Changed 3 months ago by 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

comment:13 Changed 3 months ago by markmentovai (Mark Mentovai)

Cc: markmentovai added

comment:14 Changed 3 months ago by 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.

comment:15 Changed 3 months ago by cjones051073 (Chris Jones)

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

comment:16 Changed 3 months ago by cjones051073 (Chris Jones)

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

comment:17 Changed 3 months ago by 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.

comment:18 Changed 3 months ago by 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.

comment:19 Changed 3 months ago by cjones051073 (Chris Jones)

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

comment:20 Changed 3 months ago by 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

comment:21 Changed 3 months ago by markmentovai (Mark Mentovai)

comment:22 Changed 3 months ago by markmentovai (Mark Mentovai)

Owner: set to markmentovai
Resolution: fixed
Status: newclosed

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

comment:23 Changed 3 months ago by 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.

comment:24 Changed 3 months ago by 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

comment:25 Changed 3 months ago by 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

comment:26 Changed 2 months ago by 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

comment:27 Changed 2 months ago by 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

comment:28 Changed 2 months ago by 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

comment:29 Changed 2 months ago by 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

comment:30 Changed 2 months ago by 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

comment:31 Changed 2 months ago by 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

comment:32 Changed 2 months ago by 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

comment:33 Changed 2 months ago by 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

Note: See TracTickets for help on using tickets.