[cfe-commits] [llvm-commits] (autoconf) Build ASan runtime for ARM/Android

[Evgeniy Stepanov]

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" and a platform file,
do you mean both in the compiler-rt build system (and not llvm build
system)?

On Wed, Oct 3, 2012 at 12:15 PM, Evgeniy Stepanov
<eugeni.stepanov at gmail.com> wrote:
> On Wed, Oct 3, 2012 at 4:57 AM, Eric Christopher <echristo at gmail.com> wrote:
>> On Tue, Oct 2, 2012 at 4:00 AM, Evgeniy Stepanov
>> <eugeni.stepanov at gmail.com> wrote:
>>> Yes, my first statement was incorrect.
>>>
>>> Still, these option don't help, because they (a) change the default
>>> target triple and sysroot of the resulting compiler, which may be
>>> undesirable, and (b) only let us build one flavour of compiler-rt
>>> anyway (just a different one this time).
>>>
>>
>> Well, you can pass a sysroot by command line option, changing the
>> target is a little
>> different unless you've got something like the -arch support that
>> darwin has. That said,
>> how are you building it anyhow unless you've got a compiler that supports the
>> target you're building for?
>>
>> I think I'd probably do this via a config and just have a platform
>> file for how you want
>> to do android builds. Then you can do something like "make android"
>> and it'll figure out
>> how to build it.
>
> I think my patchset has got all those things.
> We use clang from the build tree to build the runtime for android -
> that's the compiler for the target system. But we also need binutils
> (linker, at least) and a sysroot. That's what NDK is for.
>
> Are you suggesting we manually call compiler-rt's make like 'make -C
> projects/compiler-rt LLVM_ANDROID_TOOLCHAIN_DIR=/a/b/c/d' ? This is a
> bad UX (the option is undiscoverable), and the user will need to copy
> the resulting library into the appropriate clang directory by hand.
> And we need to specify the path to the ndk anyway somewhere, at least
> once.
>
>>
>> WDYT?
>>
>> -eric