[Darwin][Driver][clang] Prioritise command line args over `DEFAULT_SYSROOT` #115993

carlocab · 2024-11-13T05:18:32Z

If a toolchain is configured with DEFAULT_SYSROOT, then this could
result in an unintended value for -syslibroot being passed to the
linker if the user manually sets -isysroot or SDKROOT.

Let's fix this by prioritising command line flags when determining
-syslibroot before checking getSysRoot.

Downstream bug report: Homebrew/homebrew-core#197277

Co-authored-by: Bo Anderson [email protected]

llvmbot · 2024-11-13T05:19:06Z

@llvm/pr-subscribers-clang-driver

@llvm/pr-subscribers-clang

Author: Carlo Cabrera (carlocab)

Changes

On Darwin, clang currently prioritises -isysroot over --sysroot
when selecting headers, but does the reverse when setting -syslibroot
for the linker, which determines library selection.

This is wrong, because it leads to using headers that are of different
versions from the libraries being linked.

We can see this from:

❯ bin/clang -v -xc - -o /dev/null \
    -isysroot /Applications/Xcode-14.3.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.sdk \
    --sysroot=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX15.sdk &lt;&lt;&lt;'int main(){}'
clang version 20.0.0git (https://github.com/llvm/llvm-project.git 3de5dbb1110887d5127e815f3ca247a9d839ee85)
Target: arm64-apple-darwin24.1.0
[snip]
#include "..." search starts here:
#include &lt;...&gt; search starts here:
 /Users/carlocab/github/llvm-project/build-clang-config/lib/clang/20/include
 /Applications/Xcode-14.3.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.sdk/usr/include
 /Applications/Xcode-14.3.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.sdk/System/Library/Frameworks (framework directory)
End of search list.
 "/usr/bin/ld" -demangle -lto_library /Users/carlocab/github/llvm-project/build-clang-config/lib/libLTO.dylib -no_deduplicate -dynamic -arch arm64 -platform_version macos 13.3.0 13.3 -syslibroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX15.sdk -mllvm -enable-linkonceodr-outlining -o /dev/null /var/folders/nj/9vfk4f0n377605jhxxmngd8h0000gn/T/--b914c6.o -lSystem

We can fix this by reversing the order in which the -syslibroot flag
is determined.

Downstream bug report: Homebrew/homebrew-core#197277

Co-authored-by: Bo Anderson <[email protected]>

Full diff: https://github.com/llvm/llvm-project/pull/115993.diff

2 Files Affected:

(modified) clang/lib/Driver/ToolChains/Darwin.cpp (+6-7)
(modified) clang/test/Driver/sysroot.c (+2-2)

diff --git a/clang/lib/Driver/ToolChains/Darwin.cpp b/clang/lib/Driver/ToolChains/Darwin.cpp
index 87380869f6fdab..8bb239d8d3f9df 100644
--- a/clang/lib/Driver/ToolChains/Darwin.cpp
+++ b/clang/lib/Driver/ToolChains/Darwin.cpp
@@ -428,15 +428,14 @@ void darwin::Linker::AddLinkArgs(Compilation &C, const ArgList &Args,
   Args.AddAllArgs(CmdArgs, options::OPT_sub__library);
   Args.AddAllArgs(CmdArgs, options::OPT_sub__umbrella);
 
-  // Give --sysroot= preference, over the Apple specific behavior to also use
-  // --isysroot as the syslibroot.
-  StringRef sysroot = C.getSysRoot();
-  if (sysroot != "") {
-    CmdArgs.push_back("-syslibroot");
-    CmdArgs.push_back(C.getArgs().MakeArgString(sysroot));
-  } else if (const Arg *A = Args.getLastArg(options::OPT_isysroot)) {
+  // Prioritise -isysroot to ensure that the libraries we link to are taken
+  // from the same SDK that our headers come from.
+  if (const Arg *A = Args.getLastArg(options::OPT_isysroot)) {
     CmdArgs.push_back("-syslibroot");
     CmdArgs.push_back(A->getValue());
+  } else if (StringRef sysroot = C.getSysRoot(); sysroot != "") {
+    CmdArgs.push_back("-syslibroot");
+    CmdArgs.push_back(C.getArgs().MakeArgString(sysroot));
   }
 
   Args.AddLastArg(CmdArgs, options::OPT_twolevel__namespace);
diff --git a/clang/test/Driver/sysroot.c b/clang/test/Driver/sysroot.c
index 85da2499090af1..1e85760409a486 100644
--- a/clang/test/Driver/sysroot.c
+++ b/clang/test/Driver/sysroot.c
@@ -11,9 +11,9 @@
 // RUN: FileCheck --check-prefix=CHECK-APPLE-ISYSROOT < %t2 %s
 // CHECK-APPLE-ISYSROOT: "-arch" "i386"{{.*}} "-syslibroot" "{{[^"]*}}/FOO"
 
-// Check that honor --sysroot= over -isysroot, for Apple Darwin.
+// Check that honor -isysroot over --sysroot=, for Apple Darwin.
 // RUN: touch %t3.o
 // RUN: %clang -target i386-apple-darwin10 \
 // RUN:   -isysroot /FOO --sysroot=/BAR -### %t3.o 2> %t3
 // RUN: FileCheck --check-prefix=CHECK-APPLE-SYSROOT < %t3 %s
-// CHECK-APPLE-SYSROOT: "-arch" "i386"{{.*}} "-syslibroot" "{{[^"]*}}/BAR"
+// CHECK-APPLE-SYSROOT: "-arch" "i386"{{.*}} "-syslibroot" "{{[^"]*}}/FOO"

carlocab · 2024-11-20T09:46:05Z

Ping?

jyknight · 2024-11-27T19:46:09Z

This is the intended/expected behavior.

On every other platform, -isysroot is supposed to be an override setting the sysroot only for the header files, and never overriding the linker sysroot. The --sysroot flag, on the other hand, sets the value used for both libraries and headers (unless the header sysroot is set via -isysroot). As such, there's almost never a reason to pass -isysroot -- the right flag is --sysroot 99% of the time.

Except, on Darwin platforms, for some reason that's probably lost to history, the -isysroot is used almost universally instead of --sysroot, and a platform special-case was added to cause -isysroot to affect both the header and library sysroots -- unless the --sysroot flag is also set. This is weird and inconsistent, but it's been that way forever. The behavior was implemented very early on in Clang's development, because the pre-existing Darwin GCC port did that.

However, notably, even on Darwin, if you pass both flags, you still get the intended behavior of -isysroot affecting headers, and --sysroot affecting libraries. Your change would break that.

carlocab · 2024-11-28T14:32:04Z

However, notably, even on Darwin, if you pass both flags, you still get the intended behavior of -isysroot affecting headers, and --sysroot affecting libraries. Your change would break that.

What's the use-case for this?

Because for most users, you almost certainly don't want to mix headers and libraries of different versions, and keeping the existing behavior is essentially a big footgun when trying to build a useful toolchain on Darwin.

At Homebrew, we used to configure the toolchain with DEFAULT_SYSROOT but have recently switched that to setting the --sysroot flag in a Clang .cfg file.¹ In either case, if you set SDKROOT in your environment or try to run our clang using Apple's xcrun, this becomes equivalent to setting -isysroot and you most likely will end up with headers that mismatch the libraries you try to link to.

It seems to me that getting rid of a footgun that can impact many users (our toolchain is installed a few hundred thousand times a year, see also the downstream bug report I initially linked) might be worth breaking what currently seems to be a niche use-case of using headers and libraries of different versions. If you really wanted to do this, you can set -Wl,-syslibroot.

Of course, I'm open to alternatives that don't involve breaking anyone. (I'm similarly also open to being persuaded that mixing headers and libraries of different versions is actually not as niche as I make it out to be.)

We do this so that the toolchain can find the sysroot out of the box, when it wouldn't be able to otherwise. ↩

MaskRay · 2024-11-30T07:34:34Z

(I am not familiar with macOS and I'll defer the decision to Apple folks.
I agree with James that this PR might break users.

You probably want a different way to handle default sysroot in homebrew.
)

cyndyishida · 2024-12-02T17:15:31Z

However, notably, even on Darwin, if you pass both flags, you still get the intended behavior of -isysroot affecting headers, and --sysroot affecting libraries. Your change would break that.

What's the use-case for this?

Because for most users, you almost certainly don't want to mix headers and libraries of different versions, and keeping the existing behavior is essentially a big footgun when trying to build a useful toolchain on Darwin.

At Homebrew, we used to configure the toolchain with DEFAULT_SYSROOT but have recently switched that to setting the --sysroot flag in a Clang .cfg file.1 In either case, if you set SDKROOT in your environment or try to run our clang using Apple's xcrun, this becomes equivalent to setting -isysroot and you most likely will end up with headers that mismatch the libraries you try to link to.

The expected flow on Apple platforms is to only pass an isysroot argument whether it's inherited from xcrun -sdk <sdk version> clang or passed explicitly. Could homebrew instead only pass isysroot for Darwin targets? Or check that sysroot and isysroot inputs are the same when creating an invocation. It's unclear to me how homebrew gets into a situation where there are conflicting sdks passed for sysroot and isysroot when you effectively want to ignore whatever is passed to sysroot.

jyknight · 2024-12-02T17:34:18Z

Hm, I had a thought which might meet the needs here, and not add additional confusion: we could have the Darwin SDKROOT environment variable override both -isysroot and --sysroot. Would that help the original issue?

cachemeifyoucan · 2024-12-02T17:55:30Z

I think the correct solution for Homebrew is to never use --sysroot and switch to -isysroot since the former is almost never used on Darwin platforms.

ojhunt · 2024-12-02T20:37:18Z

Independently of the rationale for the current behaviour, I would be extremely concerned about potential breakage from this behavior change (more due to hyrum's law that intentional choices)

Bo98 · 2024-12-04T13:03:34Z

The expected flow on Apple platforms is to only pass an isysroot argument whether it's inherited from xcrun -sdk <sdk version> clang or passed explicitly. Could homebrew instead only pass isysroot for Darwin targets?

The main concern is it happens when setting DEFAULT_SYSROOT. If only isysroot is supported on macOS, does this mean DEFAULT_SYSROOT should be deprecated on Apple platforms?

Ultimately most downstream users don't really expect the need to use xcrun or pass -isysroot explicitly because Apple's Clang doesn't have that requirement - /usr/bin/clang does it implicitly and many build scripts rely on that.

cyndyishida · 2024-12-04T17:19:06Z

The main concern is it happens when setting DEFAULT_SYSROOT. If only isysroot is supported on macOS, does this mean DEFAULT_SYSROOT should be deprecated on Apple platforms?

I don't think it's deprecated in the sense we have plans to drop support for it. The problem here seems more like when those values conflict what should be expected?

Today it seems expected that sysroot will be used for library search but not header search, which also matches the other platforms. I don't know if this adds confusion or helps unblock, but clang on Darwin also respects the env var SDKROOT which translates to isysroot.

Bo98 · 2024-12-04T19:13:11Z

I don't think it's deprecated in the sense we have plans to drop support for it. The problem here seems more like when those values conflict what should be expected?

Today it seems expected that sysroot will be used for library search but not header search, which also matches the other platforms. I don't know if this adds confusion or helps unblock, but clang on Darwin also respects the env var SDKROOT which translates to isysroot.

I do agree with this and this does make sense. The problem has mostly come from two expectations:

DEFAULT_SYSROOT was expected by some users to support setting a default SDK. Maybe this wasn't actually intended, but it came common enough knowledge to eventually be explicitly recommended in parts of LLVM documentation:

llvm-project/flang/docs/GettingStarted.md

Lines 91 to 93 in ee9e786

    
           On Darwin, to make flang able to link binaries with the default sysroot without 
        
           having to specify additional flags, use the `DEFAULT_SYSROOT` CMake flag, e.g. 
        
           `-DDEFAULT_SYSROOT="$(xcrun --show-sdk-path)"`.

.

-isysroot/SDKROOT generally seems to preferred on macOS over --sysroot, despite that not being the case on other platforms.

However those two points are incompatible. And DEFAULT_SYSROOT was, until the introduction of config files recently, the only way to set a default without external wrappers as the Apple's SDK driver is closed source. We used DEFAULT_SYSROOT since the SDK changes in 10.14, but config files are becoming a possible alternative with #111387 as we could now set a default -isysroot instead with that (and we will likely do that, though does need further upstream work to make it functional for clang-tidy etc).

This probably crosses into #38193, but to paint the wider picture since I agree the problem here is more complicated than a prioritisation problem, it's generally expected from various build scripts that something like this:

#include <stdio.h>

int main() {
   printf("Hello World!");
   return 0;
}

will just work out of the box without needing extra flags or to pipe it through other commands. It works out of the box on Linux and likely most other platforms but does not on LLVM Clang for macOS (but does work with Apple /usr/bin/clang).

DEFAULT_SYSROOT was the tool reached for before but is the wrong tool it seems and it just took several years for someone to actually notice a case where it breaks I guess.

cachemeifyoucan · 2024-12-04T20:03:14Z

DEFAULT_SYSROOT was expected by some users to support setting a default SDK. Maybe this wasn't actually intended, but it came common enough knowledge to eventually be explicitly recommended in parts of LLVM documentation:

That is flang document, which is not endorsed by platform vendor in anyway. You can use DEFAULT_SYSROOT for local builds (or package manager builds for local host only) but never for products that are built for distribution on macOS. There is no standard location for macOS SDK, and it can be anywhere you want. You have to specify -isysroot or set env SDKROOT (which is what /usr/bin/clang does, it is a shim that finds the SDK location, then set SDKROOT). DEFAULT_SYSROOT can't fix any problem for distribution.

All Darwin platforms use a different model from your standard linux distribution and all SDKs are backwards compatible to older OS versions, which allows you to build software for older OS on latest version. The compilation model is closer to a cross-compilation in linux world.

The fundamental problem you hit is that you pass a secret --sysroot option (not visible from driver command) that doesn't match the -isysroot. If you intended to make this less a problem for unsuspecting users, I would change to pass -isysroot on Darwin, instead of using --sysroot for DEFAULT_SYSROOT. That should be safe enough to not disrupt any users.

Bo98 · 2024-12-04T20:29:39Z

There is no standard location for macOS SDK, and it can be anywhere you want. DEFAULT_SYSROOT can't fix any problem for distribution.

To be clear: the build I talked about there required the CLT where the SDK location is standardised, so this isn't entirely true for the use case I had. But yes a general LLVM distribution that worked with Xcode.app-only installs would require something more like xcrun which isn't implemented in LLVM Clang currently.

The major-fixed MacOSX.sdk (e.g. MacOSX15.sdk) distributed with the CLT was in fact something we requested from Apple a few years back and was agreed and implemented for the precise use case where downstream tools (mostly GCC but it ended up being used for LLVM too) needed a fixed location. (I don't have the rdar number on hand as I don't have the conversation saved but hopefully you get what I mean here)

all SDKs are backwards compatible to older OS versions, which allows you to build software for older OS on latest version

This is mostly true but there are notable exceptions such as:

libcurl in the SDK does not have OS availability APIs and it is known that using libcurl headers can lead to runtime crashes on older OS. There's possibly more but this is the example I know of
unguarded-availability-new is a warning by default and not all configure scripts set -Werror for it so will not detect feature availability properly

And we have seen these break real world applications, even high profile ones like git.

xcrun does something similar: xcrun --show-sdk-path on macOS 14.5 will prioritise the macOS 14.5 SDK over macOS 15 (but not on macOS 14.6+ because it confusingly still matches the minor version - presumably never been updated from the pre-Big Sur days), but xcrun --sdk macosx --show-sdk-path returns the latest SDK.

This doesn't really change anything here though. Distributing clang in a way that doesn't need extra flags is still an expectation the vast majority of downstream build scripts expect (which we have no control over), regardless what SDK that is.

If you intended to make this less a problem for unsuspecting users, I would change to pass -isysroot on Darwin, instead of using --sysroot for DEFAULT_SYSROOT. That should be safe enough to not disrupt any users.

DEFAULT_SYSROOT is a LLVM feature. It cannot be made to use -isysroot. (Unless you're suggesting to change LLVM here - wasn't entirely clear who that's directed to)

Migrating to config files does give us the option to use -isysroot instead and I will look into that. The v1 initial port to config files in our builds was simply a 1:1 behavioural match to the previous DEFAULT_SYSROOT behaviour. We've been contributing patches upstream to make config files work better for this use case (such as the Darwin triplet PR linked above) and getting feedback from users from edge cases where config files still aren't being applied correctly such as clang-tidy. So still using DEFAULT_SYSROOT for most builds while we experiment with config files more.

But yes: I agree avoiding --sysroot is the best option here.

cachemeifyoucan · 2024-12-04T20:52:55Z

Ah, I see. I think --sysroot is not even involved when you use DEFAULT_SYSROOT, it is injected here:
https://github.com/llvm/llvm-project/blob/main/clang/lib/Driver/Driver.cpp#L205

Maybe instead, the logic in the patch should be setting -syslibroot for linker in following order:

--sysroot
-isysroot
C.getSysRoot(), which is basically DEFAULT_SYSROOT as other cases is handled in --sysroot

I don't think DEFAULT_SYSROOT is a common setting, and if it is set, users are probably expect to overwrite using -isysroot or --sysroot.

Bo98 · 2024-12-04T20:56:37Z

That proposal makes sense to me.

carlocab · 2024-12-05T01:37:19Z

Maybe instead, the logic in the patch should be setting -syslibroot for linker in following order:

--sysroot

-isysroot

C.getSysRoot(), which is basically DEFAULT_SYSROOT as other cases is handled in --sysroot

Thanks, pushed a change that I think should implement this. Haven't gotten around to testing it yet, I will this afternoon.

carlocab · 2024-12-05T01:45:39Z

It's unclear to me how homebrew gets into a situation where there are conflicting sdks passed for sysroot and isysroot when you effectively want to ignore whatever is passed to sysroot.

Maybe this has already been answered, but just in case. You get conflicting SDKs when:

You build a toolchain that is configured with DEFAULT_SYSROOT (or, you use a Clang configuration file that uses --sysroot=, which mostly mirrors the effects of setting DEFAULT_SYSROOT)
Your user uses your toolchain and passes -isysroot to a different SDK (or, equivalently, sets SDKROOT pointing to a different SDK)

In each of the four possible scenarios above (two possibilities in each bullet point), you end up with clang using one SDK for headers (coming from -isysroot/SDKROOT) and a different one for libraries (coming from DEFAULT_SYSROOT/--sysroot).

Hm, I had a thought which might meet the needs here, and not add additional confusion: we could have the Darwin SDKROOT environment variable override both -isysroot and --sysroot. Would that help the original issue?

This would help too, actually. I'll look into this. Thanks.

I think the correct solution for Homebrew is to never use --sysroot and switch to -isysroot since the former is almost never used on Darwin platforms.

I'm looking at this in Homebrew/homebrew-core#200047. However, based on this comment, it doesn't quite solve the downstream bug report entirely. But that's something I'll have to look into.

Us switching to using -isysroot instead doesn't solve the problem of (other) users who configure a toolchain with DEFAULT_SYSROOT, but maybe the changes I've made here that you suggested at #115993 (comment) will be enough for that.

cachemeifyoucan · 2024-12-05T17:43:02Z

Current patch breaks test:

// We pass --sysroot="" to defeat any -DDEFAULT_SYSROOT parameter.

I think that just a pure hack in the test case, we can just update the test. @cyndyishida what do you think about the current approach?

carlocab · 2024-12-06T14:31:23Z

We could probably do something like

diff --git a/clang/lib/Driver/ToolChains/Darwin.cpp b/clang/lib/Driver/ToolChains/Darwin.cpp
index cdb6d21a0148..f3769ffcb4ae 100644
--- a/clang/lib/Driver/ToolChains/Darwin.cpp
+++ b/clang/lib/Driver/ToolChains/Darwin.cpp
@@ -432,7 +432,7 @@ void darwin::Linker::AddLinkArgs(Compilation &C, const ArgList &Args,
   // --isysroot as the syslibroot.
   // We check `OPT__sysroot_EQ` directly instead of `getSysRoot` to make sure we
   // prioritise command line arguments over configuration of `DEFAULT_SYSROOT`.
-  if (const Arg *A = Args.getLastArg(options::OPT__sysroot_EQ)) {
+  if (const Arg *A = Args.getLastArg(options::OPT__sysroot_EQ); A && strcmp(A->getValue(), "")) {
     CmdArgs.push_back("-syslibroot");
     CmdArgs.push_back(A->getValue());
   } else if (const Arg *A = Args.getLastArg(options::OPT_isysroot)) {

to retain the current behaviour and avoid breaking the test. Not sure it's worth going to the trouble though.

cyndyishida · 2024-12-06T17:31:36Z

Current patch breaks test:
// We pass --sysroot="" to defeat any -DDEFAULT_SYSROOT parameter.
I think that just a pure hack in the test case, we can just update the test. @cyndyishida what do you think about the current approach?

SGTM too. I don't see wide usage of it on my end. It looks like that part of test itself was added to workaround a toolchain build configuration issue, where DEFAULT_SYSROOT is actually used. I think fixing the test to adapt to the changes in the PR is the right move. More details of that in: #94284

Changing the test itself (to e.g. locally set that env var) is a good regression test that should be added for this pr anyway.

…YSROOT` If a toolchain is configured with `DEFAULT_SYSROOT`, then this could result in an unintended value for `-syslibroot` being passed to the linker if the user manually sets `-isysroot` or `SDKROOT`. Let's fix this by prioritising command line flags when determining `-syslibroot` before checking `getSysRoot`. Downstream bug report: Homebrew/homebrew-core#197277 Co-authored-by: Bo Anderson <[email protected]>

carlocab · 2024-12-09T18:25:01Z

Dropped the --sysroot="" flag from the test.

Changing the test itself (to e.g. locally set that env var) is a good regression test that should be added for this pr anyway.

Sorry, which env var are you referring to?

cyndyishida · 2024-12-09T22:13:00Z

Sorry, which env var are you referring to?

I'm suggesting an explicit test case that checks that DEFAULT_SYSROOT is set and behaves as expected. It's ignored if sysroot or isysroot is passed, it's used when they're missing.

carlocab · 2024-12-10T04:58:44Z

Sorry, which env var are you referring to?

I'm suggesting an explicit test case that checks that DEFAULT_SYSROOT is set and behaves as expected. It's ignored if sysroot or isysroot is passed, it's used when they're missing.

DEFAULT_SYSROOT is not an environment variable. It is a CMake variable/macro that must be set at configure-time:

llvm-project/clang/CMakeLists.txt

Lines 208 to 209 in aac000a

    
           set(DEFAULT_SYSROOT "" CACHE STRING 
        
             "Default <path> to all compiler invocations for --sysroot=<path>." )

llvm-project/clang/include/clang/Config/config.h.cmake

Lines 48 to 49 in aac000a

    
           /* Default <path> to all compiler invocations for --sysroot=<path>. */ 
        
           #define DEFAULT_SYSROOT "${DEFAULT_SYSROOT}"

I don't think lit knows how to tell whether DEFAULT_SYSROOT is set. We could maybe teach it to, but given that that intent of #94284 is to deprecate it (and I think all usage of it in existing builders has been removed), that seems like the wrong direction.

cachemeifyoucan

LGTM

MaskRay · 2024-12-10T17:56:26Z

The PR description (first comment), which will be used as the default commit message, should be fixed.

carlocab · 2024-12-10T18:01:14Z

The PR description (first comment), which will be used as the default commit message, should be fixed.

Thanks for the reminder, fixed.

I plan to do a few more local tests with DEFAULT_SYSROOT enabled before merging (since this isn't tested in CI).

carlocab · 2024-12-12T08:14:09Z

Tested locally; seems to be working as intended.

llvmbot added clang Clang issues not falling into any other category clang:driver 'clang' and 'clang++' user-facing binaries. Not 'clang-cl' labels Nov 13, 2024

carlocab mentioned this pull request Nov 13, 2024

llvm: Clang doesn't use SDKROOT when linking Homebrew/homebrew-core#197277

Open

4 tasks

AaronBallman requested review from MaskRay, jansvoboda11 and cyndyishida November 27, 2024 12:28

egorzhdan requested a review from ahatanak November 27, 2024 19:47

carlocab force-pushed the clang-prioritise-isysroot branch from d35918e to e257a79 Compare December 5, 2024 01:36

carlocab changed the title ~~[Darwin][Driver][clang] Prioritise -isysroot over --sysroot consistently~~ [Darwin][Driver][clang] Prioritise command line args over DEFAULT_SYSROOT Dec 5, 2024

carlocab force-pushed the clang-prioritise-isysroot branch from e257a79 to b072008 Compare December 9, 2024 18:24

cachemeifyoucan approved these changes Dec 10, 2024

View reviewed changes

carlocab merged commit 737d78a into llvm:main Dec 12, 2024
8 checks passed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[Darwin][Driver][clang] Prioritise command line args over `DEFAULT_SYSROOT` #115993

[Darwin][Driver][clang] Prioritise command line args over `DEFAULT_SYSROOT` #115993

carlocab commented Nov 13, 2024 •

edited

Loading

llvmbot commented Nov 13, 2024 •

edited

Loading

carlocab commented Nov 20, 2024

jyknight commented Nov 27, 2024

carlocab commented Nov 28, 2024 •

edited

Loading

MaskRay commented Nov 30, 2024

cyndyishida commented Dec 2, 2024

jyknight commented Dec 2, 2024

cachemeifyoucan commented Dec 2, 2024

ojhunt commented Dec 2, 2024

Bo98 commented Dec 4, 2024 •

edited

Loading

cyndyishida commented Dec 4, 2024

Bo98 commented Dec 4, 2024 •

edited

Loading

cachemeifyoucan commented Dec 4, 2024

Bo98 commented Dec 4, 2024 •

edited

Loading

cachemeifyoucan commented Dec 4, 2024 •

edited

Loading

Bo98 commented Dec 4, 2024

carlocab commented Dec 5, 2024

carlocab commented Dec 5, 2024

cachemeifyoucan commented Dec 5, 2024

carlocab commented Dec 6, 2024

cyndyishida commented Dec 6, 2024

carlocab commented Dec 9, 2024

cyndyishida commented Dec 9, 2024

carlocab commented Dec 10, 2024

cachemeifyoucan left a comment

MaskRay commented Dec 10, 2024

carlocab commented Dec 10, 2024

carlocab commented Dec 12, 2024

[Darwin][Driver][clang] Prioritise command line args over DEFAULT_SYSROOT #115993

[Darwin][Driver][clang] Prioritise command line args over DEFAULT_SYSROOT #115993

Conversation

carlocab commented Nov 13, 2024 • edited Loading

llvmbot commented Nov 13, 2024 • edited Loading

carlocab commented Nov 20, 2024

jyknight commented Nov 27, 2024

carlocab commented Nov 28, 2024 • edited Loading

Footnotes

MaskRay commented Nov 30, 2024

cyndyishida commented Dec 2, 2024

jyknight commented Dec 2, 2024

cachemeifyoucan commented Dec 2, 2024

ojhunt commented Dec 2, 2024

Bo98 commented Dec 4, 2024 • edited Loading

cyndyishida commented Dec 4, 2024

Bo98 commented Dec 4, 2024 • edited Loading

cachemeifyoucan commented Dec 4, 2024

Bo98 commented Dec 4, 2024 • edited Loading

cachemeifyoucan commented Dec 4, 2024 • edited Loading

Bo98 commented Dec 4, 2024

carlocab commented Dec 5, 2024

carlocab commented Dec 5, 2024

cachemeifyoucan commented Dec 5, 2024

carlocab commented Dec 6, 2024

cyndyishida commented Dec 6, 2024

carlocab commented Dec 9, 2024

cyndyishida commented Dec 9, 2024

carlocab commented Dec 10, 2024

cachemeifyoucan left a comment

Choose a reason for hiding this comment

MaskRay commented Dec 10, 2024

carlocab commented Dec 10, 2024

carlocab commented Dec 12, 2024

[Darwin][Driver][clang] Prioritise command line args over `DEFAULT_SYSROOT` #115993

[Darwin][Driver][clang] Prioritise command line args over `DEFAULT_SYSROOT` #115993

carlocab commented Nov 13, 2024 •

edited

Loading

llvmbot commented Nov 13, 2024 •

edited

Loading

carlocab commented Nov 28, 2024 •

edited

Loading

Bo98 commented Dec 4, 2024 •

edited

Loading

Bo98 commented Dec 4, 2024 •

edited

Loading

Bo98 commented Dec 4, 2024 •

edited

Loading

cachemeifyoucan commented Dec 4, 2024 •

edited

Loading