User Details
- User Since
- Jun 19 2014, 10:59 AM (344 w, 13 h)
Today
Thanks! Has been up for a while and I haven't heard any objections. Will submit and we can revert if issues are found.
Dec 14 2020
Ping.
Dec 2 2020
Nov 17 2020
Nov 6 2020
Ping
Oct 28 2020
Oct 27 2020
Oct 26 2020
Oct 12 2020
LGTM for Android.
Sep 23 2020
Aug 20 2020
Jun 17 2020
Jun 1 2020
May 21 2020
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.
Apr 29 2020
Apr 24 2020
Apr 23 2020
@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.
Apr 16 2020
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:
Apr 7 2020
Added missing copyright header and moved into the libcxx specific test directory.
Apr 6 2020
Mar 30 2020
Mar 26 2020
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.
Mar 20 2020
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.
Mar 19 2020
Thanks for fixing this 👍
Mar 17 2020
Ping.
Mar 13 2020
(remove some trailing whitespace that snuck in)
Add .fail test, merge into single macro.
Yep, good point. I think we don't run the full libc++ test suite for the broken configuration. Fixed.
Mar 12 2020
PTAL
Jan 28 2020
We don't build the NDK's libc++ with CMake. What's the motivation for this?
Jan 6 2020
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.
Dec 6 2019
Nov 18 2019
Nov 6 2019
LGTM
Fix a couple missing bits in the instructions.
Oct 17 2019
Oct 15 2019
Oct 4 2019
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.