We don't build the NDK's libc++ with CMake. What's the motivation for this?
Tue, Jan 28
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
Fix a couple missing bits in the instructions.
Oct 17 2019
Independently, I am wondering if there's a better way to link the process id to a bundle. Using argv 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.
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.
Oct 3 2019
If the Android and FreeBSD folks are ok with this, I'm fine with it
Sep 26 2019
Sep 18 2019
Sep 16 2019
Thanks for the heads up. I've reverted the patch.
Closed by https://reviews.llvm.org/rL372016
Sep 9 2019
LGTM. @EricWF any further comments before I submit this?
Sep 5 2019
Jul 22 2019
Jul 16 2019
MSan won't currently help us on Android (and I don't think there's a plan to support that any time soon, but eugenis would know better).
Jul 15 2019
I think for Android we'd rather have the debuggability, but +enh for a second opinion.
Jul 11 2019
Jul 2 2019
For example, when we're building against the Android NDK, we might want to use the NDK's C++ headers (which have a custom inline namespace) even if we have C++ headers installed next to the driver.
May 6 2019
May 1 2019
Apr 16 2019
@EricWF Any concerns, or can I merge this?
Apr 2 2019
Only opt-in for bionic
Apr 1 2019
I'm not really sure who speaks for glibc platforms. @EricWF? Like I said, if we're not comfortable making this change for glibc I don't have a problem backing that out, but I do think this is a more useful default behavior. It's fairly convoluted to pass a file descriptor from an fstream across an exec boundary intentionally so I somewhat doubt anyone is doing so intentionally. Anyone doing so unintentionally is just leaking an fd and any use of it on the other side of the exec is probably a bug.
Add a comment explaining _LIBCPP_FOPEN_CLOEXEC_MODE.
Mar 29 2019
Android maintains its own build scripts, so this won't harm us, but I think the problem in general remains. Seems like it would be better for the webasm target to opt out of the behavior than for all targets to do it (or maybe just provide an option so maintainers can choose what they want for their platform).
Mar 28 2019
Mar 27 2019
I'm mostly worried about the change in behavior breaking existing programs.
Mar 26 2019
Feb 21 2019
Feb 20 2019
Updated to address some review comments:
Feb 15 2019
Feb 13 2019
The official documentation still says "Your app must perform runtime detection to confirm that NEON-capable machine code can be run on the target device" (https://developer.android.com/ndk/guides/cpu-arm-neon#runtime_detection). Is that wrong?
Feb 12 2019
Jan 15 2019
Jan 11 2019
Added reference to spec in comment.