Thanks, r166559, r166560.
I'd be happy to rewrite this once we have agreement on how to do this
in a more maintainable way. I'm not really happy with the out-of-tree
approach you mentioned, because it puts additional burden on the
people who do the actual build, forcing them to remember long,
Not particularly happy about it, but it seems like it'll be fine for
now if it unblocks some progress you'd like to make.
-eric
On Thu, Oct 18, 2012 at 8:16 AM, Evgeniy Stepanov
eugeni.stepa...@gmail.com wrote:
ping
On Wed, Oct 17, 2012 at 6:34 PM, Evgeniy Stepanov
eugeni.stepa...@gmail.com
ping
On Wed, Oct 17, 2012 at 6:34 PM, Evgeniy Stepanov
eugeni.stepa...@gmail.com wrote:
OK, let's get rid of the configure option for the sake of progress.
Please take another look.
This way android runtime can be built with an extra make invocation in
the same build tree.
make -C
OK, let's get rid of the configure option for the sake of progress.
Please take another look.
This way android runtime can be built with an extra make invocation in
the same build tree.
make -C tools/clang/runtime/ LLVM_ANDROID_TOOLCHAIN_DIR=/path/to/ndk/toolchain
On Thu, Oct 11, 2012 at 1:50
Nothing really.
Let's look at it this way. As things are, I can build
llvm+clang+compiler-rt combo that can target both x86_64 and i386.
$ ls lib/clang/3.2/lib/linux/ | cat
libclang_rt.asan-i386.a
libclang_rt.asan-x86_64.a
libclang_rt.i386.a
libclang_rt.tsan-x86_64.a
libclang_rt.x86_64.a
Now, I
Let's look at it this way. As things are, I can build
llvm+clang+compiler-rt combo that can target both x86_64 and i386.
$ ls lib/clang/3.2/lib/linux/ | cat
libclang_rt.asan-i386.a
libclang_rt.asan-x86_64.a
libclang_rt.i386.a
libclang_rt.tsan-x86_64.a
libclang_rt.x86_64.a
Now, I want to
Otherwise I think it starts to become an unwieldy set of configure flags
to set any sdk/sysroot that any particular target triple needs in building
any of the runtime libraries (libcxx will necessarily have this problem too).
Thoughts?
FWIW Jim, Chandler and I have been discussing this as
What about the Android NDK requires special handling that isn't already done
for a sysroot?
Sent from my iPad
On Oct 8, 2012, at 2:28 AM, Evgeniy Stepanov eugeni.stepa...@gmail.com wrote:
I have re-read this discussion and no longer understand what we are
disagreeing on. Are you opposed to
I have re-read this discussion and no longer understand what we are
disagreeing on. Are you opposed to the --with-android-toolchain
option? What if we call it --with-android-ndk to avoid confusion
with the similar-named option for the gcc toolchain?
Also, in your last message about make android
What's wrong with using --with-sysroot and the --target to determine
this information?
-eric
On Fri, Sep 28, 2012 at 5:17 AM, Evgeniy Stepanov
eugeni.stepa...@gmail.com wrote:
Hi,
these patched enable building the ARM/Android runtime library for
AddressSanitizer if Android NDK is available.
10 matches
Mail list logo
