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

[Evgeniy Stepanov]

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 want to add arm-android to the mix. I.e., I'd like to build
clang that can target all three (at least these three) platforms, and
compiler-rt libraries for all of them.

To do that, I need to specify the path to android ndk somewhere. If I
use --with-default-sysroot option, I'll get a clang binary that
targets the ndk by default (this is bad already). Then I'll need to
somehow cancel that in compiler-rt build system to build x86_64 and
i386 libraries. That would be a mess, and we lose the ability to
choose the default sysroot of the resulting compiler on the way.

Compiler-rt (and clang) build system already has some simple
autodetection of the supported targets to build either i386, or x86_64
runtime, or both of them. I'm just adding the capability to detect and
build the android runtime as well, but that requires a configure
option, because there is no standard path where the android ndk can be
located.

Does it make any sense? Please let me know if there is something I've missed.

On Wed, Oct 10, 2012 at 5:54 AM, Alex Rosenberg <alexr at leftfield.org> wrote:
> 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.stepanov at gmail.com> wrote:
>
>> 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
>> _______________________________________________
>> cfe-commits mailing list
>> cfe-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>>