Re: [cfe-commits] [llvm-commits] (autoconf) Build ASan runtime for ARM/Android
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, magical make lines. Making it more complex with make it less well-tested. Multiple SDKs and build environments are a fact of life, and the best we can do is embed the knowledge of them in the build system without an explosion in its complexity (linear growth is fine in my book). On Sat, Oct 20, 2012 at 12:04 AM, Eric Christopher echri...@gmail.com wrote: 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 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 tools/clang/runtime/ LLVM_ANDROID_TOOLCHAIN_DIR=/path/to/ndk/toolchain On Thu, Oct 11, 2012 at 1:50 AM, Eric Christopher echri...@gmail.com wrote: 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 well. Been going over how to deal with in versus out of tree builds and options for a full toolchain. Just wanted to let you know it's more than just a couple of people chatting :) -eric ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [cfe-commits] [llvm-commits] (autoconf) Build ASan runtime for ARM/Android
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 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 tools/clang/runtime/ LLVM_ANDROID_TOOLCHAIN_DIR=/path/to/ndk/toolchain On Thu, Oct 11, 2012 at 1:50 AM, Eric Christopher echri...@gmail.com wrote: 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 well. Been going over how to deal with in versus out of tree builds and options for a full toolchain. Just wanted to let you know it's more than just a couple of people chatting :) -eric ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [cfe-commits] [llvm-commits] (autoconf) Build ASan runtime for ARM/Android
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 tools/clang/runtime/ LLVM_ANDROID_TOOLCHAIN_DIR=/path/to/ndk/toolchain On Thu, Oct 11, 2012 at 1:50 AM, Eric Christopher echri...@gmail.com wrote: 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 well. Been going over how to deal with in versus out of tree builds and options for a full toolchain. Just wanted to let you know it's more than just a couple of people chatting :) -eric ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [cfe-commits] [llvm-commits] (autoconf) Build ASan runtime for ARM/Android
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 AM, Eric Christopher echri...@gmail.com wrote: 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 well. Been going over how to deal with in versus out of tree builds and options for a full toolchain. Just wanted to let you know it's more than just a couple of people chatting :) -eric clang.patch Description: Binary data compiler-rt.patch Description: Binary data ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [cfe-commits] [llvm-commits] (autoconf) Build ASan runtime for ARM/Android
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 al...@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.stepa...@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.stepa...@gmail.com wrote: On Wed, Oct 3, 2012 at 4:57 AM, Eric Christopher echri...@gmail.com wrote: On Tue, Oct 2, 2012 at 4:00 AM, Evgeniy Stepanov eugeni.stepa...@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@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [cfe-commits] [llvm-commits] (autoconf) Build ASan runtime for ARM/Android
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. Great explanation, and no, I don't think you've missed anything. I think that this is going to be a general problem; i.e. what if you wanted to build both an arm and mips android compiler-rt at the same time? A command-line sysroot will solve the location of the sysroot but won't handle the problem of building n versions of compiler-rt all at once. I was leaning towards a solution of build them individually out of tree and then just use make variables to set the location of things needed by each individual build rather than trying to build everything possible in tree in one build. 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? -eric ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [cfe-commits] [llvm-commits] (autoconf) Build ASan runtime for ARM/Android
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 well. Been going over how to deal with in versus out of tree builds and options for a full toolchain. Just wanted to let you know it's more than just a couple of people chatting :) -eric ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [cfe-commits] [llvm-commits] (autoconf) Build ASan runtime for ARM/Android
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 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.stepa...@gmail.com wrote: On Wed, Oct 3, 2012 at 4:57 AM, Eric Christopher echri...@gmail.com wrote: On Tue, Oct 2, 2012 at 4:00 AM, Evgeniy Stepanov eugeni.stepa...@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@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [cfe-commits] [llvm-commits] (autoconf) Build ASan runtime for ARM/Android
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.stepa...@gmail.com wrote: On Wed, Oct 3, 2012 at 4:57 AM, Eric Christopher echri...@gmail.com wrote: On Tue, Oct 2, 2012 at 4:00 AM, Evgeniy Stepanov eugeni.stepa...@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@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [cfe-commits] [llvm-commits] (autoconf) Build ASan runtime for ARM/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. They add a 'configure' option, --with-android-toolchain, that, when pointed to a standalone toolchain from the Android NDK, enables building the runtime library. WDYT? Is this in the right general direction? We could later support simultaneous building of i386 and x86_64 runtimes on multilib systems the same way - a configure test in LLVM, and a conditional configuration in compiler-rt. ___ llvm-commits mailing list llvm-comm...@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
