clang-15, llvm-15: restore functionality on macOS 15 (Xcode 16) #25918
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This was referenced Sep 25, 2024
12 tasks
This is a cherry-pick of llvm/llvm-project@73e15b5. 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: https://trac.macports.org/ticket/70779
markmentovai
force-pushed
the
clang-15_xcode-16
branch
from
152e960 to
63b9b2f
Compare
|
@markmentovai testing this on macOS15(arm64). Whilst it builds, I get the following compiling a simple c++17 test case whilst the build seems OK, the above seems worrying. Not sure I would want to enable this as an allowed fallback with them. |
|
Note, I am not saying we should not push this, eventually, just given the above I will probably refrain from adding it back to the default list of clang fallback compilers, or the list of clang versions in the compilers PG because of this. mp-clang-16+ really should be enough, and a lot better than 18+. |
|
Thanks for testing, @cjones051073. I'll have a look at that (and the same in clang-14) tomorrow. |
|
I’d like to fix this. Aside from the noise, letting dyld intentionally mis-resolve symbols that it can’t find with sentinel values is pretty bad. I’d prefer it just crash outright. Yuck. As your example showed, this is happening during linking. About as reduced as possible: PID 1133 in that example is The “invalidates PrebuiltLoader” messages that refer to libc++abi.dylib are relevant. It appears that /opt/local/libexec/llvm-15/lib/libc++abi.dylib (from clang-15) is being loaded for some reason, and is being used in place of the Apple-shipped libc++abi at /usr/lib/libc++abi.dylib (via the dyld shared cache). Removing llvm-15’s libLTO.dylib LTO plug-in quiets things down (just as a test, not a solution): And indeed, /opt/local/libexec/llvm-15/lib/libc++abi.dylib doesn’t provide That’s unsurprising because it’s one of the brand-new “symbols that are present in the system libc++ on Apple platforms but are not implemented in upstream libc++” mentioned by llvm libcxxabi/src/vendor/apple/shims.cpp. Nasty override, and it’s very un-Mach-O two-level namespace-like. How’s it happening at all? Probably Confirmed, What’s actually happening is that /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld is re- In fact, I can give a bad filename (but a good path) to It’s bad fortune, and part coincidence, that there’s a copy of clang-15’s libc++abi.dylib right next to libLTO.dylib in /opt/local/libexec/llvm-15/lib. So why’s this a problem for clang-14 and clang-15, but not clang-16 and higher? Because clang-16 and higher don’t keep a copy of libc++abi.dylib there right next to libLTO.dylib! Instead, it’s safely tucked away a level deeper: Hey, how’d that happen? clang-16 has this. (So do later versions.) clang-15 does not. (Neither do earlier versions.) This was done just a couple of months ago in a1d4865, bug 68640. Any reason you didn’t carry this back to older versions of clang? |
|
Thanks for that investigation ! I cannot recall the exact reason I stopped at clang-16 with that, perhaps I thought that 'enough'. In any case, seeing as you have these PRs open would you mind replicating the changes in to clang 14 and 15 ? |
markmentovai
added a commit
to markmentovai/macports-ports
that referenced
this pull request
Sep 26, 2024
This applies a1d4865, which addressed this for clang-16–18 for https://trac.macports.org/ticket/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-`execve`ing 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 the same directory to satisfy any other Mach-O load command. In this case, the directory contained both libc++.1.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 '__ZnwmSt19__type_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 '__ZdlPvSt19__type_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 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 macports#25918 with another change that updates clang-15’s revision. References: https://trac.macports.org/ticket/70779
markmentovai
force-pushed
the
clang-15_xcode-16
branch
from
63b9b2f to
b90ae9c
Compare
|
This pull request and the clang-14 one have been updated to move those libraries out of the way, in line with a1d4865. But…
I may have found why you stopped at clang-16. And I think I know what’s broken. Those absolute paths to /opt/local/libexec/llvm-15/lib aren’t happy when the libraries are moved to /opt/local/libexec/llvm-15/lib/libc++. Compare clang-16: This happens with clang-14 too. Scanning clang-14/main.log, these are the only two occurrences of Examining diffs in the CMake build between llvm-15 and llvm-16, llvm/llvm-project@b98da4c stuck out as perhaps being relevant, but it’s partially reverted in MacPorts by 591281e (for bug 67686). Possibly the llvm/cmake/modules/AddLLVM.cmake change can still be backported, even while leaving llvm/cmake/modules/AddLLVM.cmake out of it. |
Nope, that’s not it. And looking at the change to AddLLVM.cmake more closely, it’s effectively a no-op on Apple. |
|
I can’t reproduce the absolute-path |
|
I converted this and #25919 to a draft, because they shouldn’t be merged until the above can be addressed. |
|
That Interestingly, the same problem affects clang-16 via lang/llvm-16/Portfile, and its But, through some difference between clang-15 and clang-16, it’s not a problem in that version or later versions. As I noted earlier in #25918 (comment), even with clang-15, most libraries aren’t getting Regardless, it’s clear that this was always intended to be a removal from This should be an easy and correct fix, but it will need to be applied to llvm-12 and later. |
This applies a1d4865, which addressed this for clang-16–18 for https://trac.macports.org/ticket/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-`execve`ing 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 '__ZnwmSt19__type_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 '__ZdlPvSt19__type_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 macports#25918 (comment). 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 macports#25918 with another change that updates clang-15’s revision. References: https://trac.macports.org/ticket/70779
This is a cherry-pick of: llvm/llvm-project@c57c7b7 llvm/llvm-project@7939ce3 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: https://trac.macports.org/ticket/70779
markmentovai
force-pushed
the
clang-15_xcode-16
branch
from
b90ae9c to
f37ff39
Compare
markmentovai
added a commit
to markmentovai/macports-ports
that referenced
this pull request
Sep 27, 2024
This applies a1d4865, which addressed this for clang-16–18 for https://trac.macports.org/ticket/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-`execve`ing 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 '__ZnwmSt19__type_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 '__ZdlPvSt19__type_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 macports#25918 (comment). 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 macports#25919 with another change that updates clang-14’s revision. References: https://trac.macports.org/ticket/70779
|
Should be all fixed now. No library overrides, unresolved symbols, or .dylibs with bad install names or attempting to load other .dylibs at nonexistent paths. |
cjones051073
pushed a commit
that referenced
this pull request
Sep 27, 2024
This applies a1d4865, which addressed this for clang-16–18 for https://trac.macports.org/ticket/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-`execve`ing 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 '__ZnwmSt19__type_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 '__ZdlPvSt19__type_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 #25918 (comment). 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 #25918 with another change that updates clang-15’s revision. References: https://trac.macports.org/ticket/70779
|
thanks, tested locally first and all fine :) |
cjones051073
pushed a commit
that referenced
this pull request
Sep 27, 2024
This applies a1d4865, which addressed this for clang-16–18 for https://trac.macports.org/ticket/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-`execve`ing 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 '__ZnwmSt19__type_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 '__ZdlPvSt19__type_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 #25918 (comment). 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 #25919 with another change that updates clang-14’s revision. References: https://trac.macports.org/ticket/70779
markmentovai
added a commit
to markmentovai/macports-ports
that referenced
this pull request
Sep 27, 2024
The Portfiles for these llvm versions were mishandling CMAKE_INSTALL_NAME_DIR in configure.pre_args-delete, failing to delete the intended variable set by the _resources/port1.0/group/cmake-1.0.tcl port group because the port group enclosed the value in quotes, but the Portfile omitted them. CMAKE_INSTALL_RPATH was being mishandled in the same way, but because these Portfiles specify cmake.install_rpath as empty, the port group was not setting CMAKE_INSTALL_RPATH at all, so the configure.pre_args-delete entry for that variable can be removed from the Portfiles altogether. These Portfiles’ configure.pre_args-replace item for CMAKE_SYSTEM_PREFIX_PATH has been updated to reflect the value actually set by the port group. For llvm-16 and later, these Portfile updates should not cause any meaningful change to the build output, so these Portfiles’ `revision` fields are not updated. This same change would have impact to llvm-15 and earlier. llvm-15 was handled more carefully in macports#25918, and llvm-14 in macports#25919. A more comprehensive explanation of the change appears at macports#25918 (comment).
markmentovai
added a commit
to markmentovai/macports-ports
that referenced
this pull request
Sep 27, 2024
The Portfiles for these llvm versions were mishandling CMAKE_INSTALL_NAME_DIR in configure.pre_args-delete, failing to delete the intended variable set by the _resources/port1.0/group/cmake-1.0.tcl port group because the port group enclosed the value in quotes, but the Portfiles omitted them. CMAKE_INSTALL_RPATH was being mishandled in the same way, but because these Portfiles specify cmake.install_rpath as empty, the port group was not setting CMAKE_INSTALL_RPATH at all, so the configure.pre_args-delete entry for that variable can be removed from the Portfiles altogether. These Portfiles’ configure.pre_args-replace item for CMAKE_SYSTEM_PREFIX_PATH has been updated to reflect the value actually set by the port group. For llvm-16 and later, these Portfile updates should not cause any meaningful change to the build output, so these Portfiles’ `revision` fields are not updated. This same change would have impact to llvm-15 and earlier. llvm-15 was handled more carefully in macports#25918, and llvm-14 in macports#25919. A more comprehensive explanation of the change appears at macports#25918 (comment).
markmentovai
added a commit
to markmentovai/macports-ports
that referenced
this pull request
Sep 27, 2024
The Portfiles for these llvm versions were mishandling CMAKE_INSTALL_NAME_DIR in configure.pre_args-delete, failing to delete the intended variable set by the _resources/port1.0/group/cmake-1.1.tcl port group because the port group enclosed the value in quotes, but the Portfiles omitted them. CMAKE_INSTALL_RPATH was being mishandled in the same way, but because these Portfiles specify cmake.install_rpath as empty, the port group was not setting CMAKE_INSTALL_RPATH at all, so the configure.pre_args-delete entry for that variable can be removed from the Portfiles altogether. These Portfiles’ configure.pre_args-replace item for CMAKE_SYSTEM_PREFIX_PATH has been updated to reflect the value actually set by the port group. For llvm-16 and later, these Portfile updates should not cause any meaningful change to the build output, so these Portfiles’ `revision` fields are not updated. This same change would have impact to llvm-15 and earlier. llvm-15 was handled more carefully in macports#25918, and llvm-14 in macports#25919. A more comprehensive explanation of the change appears at macports#25918 (comment).
markmentovai
added a commit
to markmentovai/macports-ports
that referenced
this pull request
Sep 27, 2024
The Portfiles for these llvm versions were mishandling CMAKE_INSTALL_NAME_DIR in configure.pre_args-delete, failing to delete the intended variable set by the _resources/port1.0/group/cmake-1.1.tcl port group because the port group enclosed the value in quotes, but the Portfiles omitted the quotes. CMAKE_INSTALL_RPATH was being mishandled in the same way, but because these Portfiles specify cmake.install_rpath as empty, the port group was not setting CMAKE_INSTALL_RPATH at all, so the configure.pre_args-delete entry for that variable can be removed from the Portfiles altogether. These Portfiles’ configure.pre_args-replace item for CMAKE_SYSTEM_PREFIX_PATH has been updated to reflect the value actually set by the port group. For llvm-16 and later, these Portfile updates should not cause any meaningful change to the build output, so these Portfiles’ `revision` fields are not updated. This same change would have impact to llvm-15 and earlier. llvm-15 was handled more carefully in macports#25918, and llvm-14 in macports#25919. A more comprehensive explanation of the change appears at macports#25918 (comment).
markmentovai
added a commit
to markmentovai/macports-ports
that referenced
this pull request
Sep 27, 2024
The Portfiles for these llvm versions were mishandling CMAKE_INSTALL_NAME_DIR in configure.pre_args-delete, failing to delete the intended variable set by the _resources/port1.0/group/cmake-1.1.tcl port group because the port group encloses the value in quotes, but the Portfiles omitted the quotes. CMAKE_INSTALL_RPATH was being mishandled in the same way, but because these Portfiles specify cmake.install_rpath as empty, the port group does not set CMAKE_INSTALL_RPATH at all, so the configure.pre_args-delete entry for that variable can be removed from the Portfiles altogether. These Portfiles’ configure.pre_args-replace item for CMAKE_SYSTEM_PREFIX_PATH has been updated to reflect the value actually set by the port group. For llvm-16 and later, these Portfile updates should not cause any meaningful change to the build output, so these Portfiles’ `revision` fields are not updated. This same change would have impact to llvm-15 and earlier. llvm-15 was handled more carefully in macports#25918, and llvm-14 in macports#25919. A more comprehensive explanation of the change appears at macports#25918 (comment).
12 tasks
cjones051073
pushed a commit
that referenced
this pull request
Sep 28, 2024
The Portfiles for these llvm versions were mishandling CMAKE_INSTALL_NAME_DIR in configure.pre_args-delete, failing to delete the intended variable set by the _resources/port1.0/group/cmake-1.1.tcl port group because the port group encloses the value in quotes, but the Portfiles omitted the quotes. CMAKE_INSTALL_RPATH was being mishandled in the same way, but because these Portfiles specify cmake.install_rpath as empty, the port group does not set CMAKE_INSTALL_RPATH at all, so the configure.pre_args-delete entry for that variable can be removed from the Portfiles altogether. These Portfiles’ configure.pre_args-replace item for CMAKE_SYSTEM_PREFIX_PATH has been updated to reflect the value actually set by the port group. For llvm-16 and later, these Portfile updates should not cause any meaningful change to the build output, so these Portfiles’ `revision` fields are not updated. This same change would have impact to llvm-15 and earlier. llvm-15 was handled more carefully in #25918, and llvm-14 in #25919. A more comprehensive explanation of the change appears at #25918 (comment).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a cherry-pick of:
llvm/llvm-project@c57c7b7 llvm/llvm-project@7939ce3
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: https://trac.macports.org/ticket/70779
Description
Type(s)
Tested on
macOS 15.0 24A335 arm64
Xcode 16.0 16A242d
Verification
Have you
port lint --nitpick?sudo port test?sudo port -vst install?@cjones051073