Thanks! Has been up for a while and I haven't heard any objections. Will submit and we can revert if issues are found.

https://github.com/llvm/llvm-project/commit/0849047860a343d8bcf1f828a82d585e89079943

Ping.

Ping

In D87950#2354838, @ldionne wrote:

Actually, talk about timing! The Clang patch was just posted here: https://reviews.llvm.org/D90188

LGTM for Android.

In D81622#2094409, @ldionne wrote:

While this doesn't look wrong to me -- and the correctness of this depends entirely on where vendors decide to put their headers so it's hard for me to verify -- I'm wondering why not all toolchains use this mechanism. We seem to be adding an abstraction that's used only by some toolchains, but not all. I think it would be great to have a single canonical way of representing the system root.

The NDK still supports linkers other than LLD, but we are changing the default to LLD in the next release. I'd prefer to keep this for the time being, but don't feel strongly about it.

In D76452#2002981, @danalbert wrote:

In D76452#2002917, @MaskRay wrote:

In D76452#2002875, @danalbert wrote:

In D76452#2002856, @int3 wrote:

Yes, I was referring to that question too :) I'm working on the new lld-macho implementation, under the DarwinNew flavor. I'm not sure if anything depends on the old Darwin flavor, which is why we haven't removed it yet, though we plan to do that once we get the new implementation to a more mature stage.

Ah, gotcha :) Thanks! Will wait for @ruiu to chime in.

I vote for deleting the #ifdef __APPLE__ chunk so we don't have to add more code to either clang or lld....
The code owner of the existing lld darwin has explicitly expressed that we can drop the existing Darwin flavor at any time.

SGTM. Abandoning this. I'll send a patch to remove the LLD side shortly.

In D76452#2002917, @MaskRay wrote:

In D76452#2002875, @danalbert wrote:

In D76452#2002856, @int3 wrote:

Yes, I was referring to that question too :) I'm working on the new lld-macho implementation, under the DarwinNew flavor. I'm not sure if anything depends on the old Darwin flavor, which is why we haven't removed it yet, though we plan to do that once we get the new implementation to a more mature stage.

Ah, gotcha :) Thanks! Will wait for @ruiu to chime in.

I vote for deleting the #ifdef __APPLE__ chunk so we don't have to add more code to either clang or lld....
The code owner of the existing lld darwin has explicitly expressed that we can drop the existing Darwin flavor at any time.

In D76452#2002856, @int3 wrote:

Yes, I was referring to that question too :) I'm working on the new lld-macho implementation, under the DarwinNew flavor. I'm not sure if anything depends on the old Darwin flavor, which is why we haven't removed it yet, though we plan to do that once we get the new implementation to a more mature stage.

In D76452#2002620, @int3 wrote:

I don't think I have enough context here to answer the question, but I'm pretty sure that change wouldn't affect what I'm working on

In D76452#2000812, @nickdesaulniers wrote:

Can we use -DCLANG_DEFAULT_LINKER=lld to configure AOSP's distribution of LLD, then require the use of -fuse-ld=<whatever the host linker is on OSX that is currently used> when targeting OSX host tools?

@srhines to confirm that this won't break our toolchain build, and @rprichard because he's the one looking more closely at libunwind these days.

Option 4 was (at least on the surface) super easy: https://reviews.llvm.org/D78328. lmk if you'd prefer that approach. I'm slightly less confident in it since it affects non-Android platforms as well.

@MaskRay Any other ideas, or should I submit this? Reviewing all our options:

Added missing copyright header and moved into the libcxx specific test directory.

In D76452#1945084, @srhines wrote:

In D76452#1945029, @MaskRay wrote:

To cross build ELF object on macOS, another alternative is a wrapper named ld which invokes lld -flavor gnu "$@"

@danalbert Would this kind of idea work with your other reverted patch? I'm not sure exactly what broke on those builds.

It seems I'd goofed something in my testing earlier (I think I still had -fuse-ld=lld force on in my build system). While Clang will find ld in the driver directory and prefer it, LLD defaults to the Darwin driver mode when argv[0] is ld when run on Darwin. We need GNU mode, and the best way to get this behavior is to have Clang invoke ld.lld instead.

Looks like we don't actually need this. Can achieve the same effect by installing ld.lld to the same directory as Clang as ld and it'll be preferred over the other locations.

Thanks for fixing this 👍

Ping.

(remove some trailing whitespace that snuck in)

Add .fail test, merge into single macro.

In D76091#1922250, @EricWF wrote:

Some of the changes in this patch are not correct. Please revert them in a follow up commit.

Yep, good point. I think we don't run the full libc++ test suite for the broken configuration. Fixed.

PTAL

We don't build the NDK's libc++ with CMake. What's the motivation for this?

Just to clarify, this is needed for the triple-prefixed tools, but the triple-specific directory worked fine before this patch? If I'm understanding that correctly then LGTM, otherwise I'm confused as to why I haven't seen this problem before.

https://github.com/llvm/llvm-project/commit/19fd9039ca242f408493b5c662f9d908eab8555e

https://github.com/llvm/llvm-project/commit/626260cfe3c7a5d9747f0bf13d87fa1855eb74bb

LGTM

Fix a couple missing bits in the instructions.

In D68968#1710520, @labath wrote:

Independently, I am wondering if there's a better way to link the process id to a bundle. Using argv[0] might be ok if we're using it just for display purposes, but if we're going to be doing other stuff based on that identifier, it would be better to get it from a more reliable source. Unfortunately, I was not able to find a more "reasonable source", but maybe @danalbert has an idea.

The alternative would be to only provide new/delete inside libc++abi, not in libc++ (by default). So, vendors (@phosek @srhines @danalbert @dim @emaste), are you OK with the default becoming that libc++abi provides new/delete, and libc++ DOES NOT (by default). If you want to keep shipping new/delete as part of libc++, you'll need to specify -DLIBCXX_ENABLE_NEW_DELETE_DEFINITIONS=ON at CMake configure time.