search for: try_compiles

In the effort to flesh out the CMake build system a problematic issue has come up, and I’d like some feedback on how to best handle it. For reference this issue has been reported by a few users, one proposed patches that don’t really address the underlying problem here: http://reviews.llvm.org/D13131 The problem comes when bootstrapping a cross-compiler toolchain. In order to have a

This is currently a rough area in our build system, but there are two CMake options you probably need to set. (1) -DLLVM_BUILD_EXTERNAL_COMPILER_RT=On —> This option causes the build to use the just-built clang when building compiler-rt (2) -DCOMPILER_RT_DEFAULT_TARGET_ARCH=??? —> This is where you specify which architecture you want to build the compiler-rt archives and libraries for

Lei, The issues that you’re reporting here are on my mind. I have a patch out for review now (http://reviews.llvm.org/D19742 <http://reviews.llvm.org/D19742>) that allows building builtins without a full toolchain. One of the next steps after this is to support alternate sysroots for different targets, and to identify builtins that need target headers so that they can be excluded in cases

Hi List! Attached is a patch to configure.in to test that epoll, poll, inotify, kqueue and dnotify actually work. It also attempts to select the best one for you if none specified. This supercedes my previous patch in the re beta9 thread. Hopefully get this in Gentoo's beta9 ebuild soon. Thanks -- Roy Marples <uberlord@gentoo.org> Gentoo/Linux Developer (baselayout, networking)

> On Nov 2, 2015, at 10:10 AM, Anton Korobeynikov <anton at korobeynikov.info> wrote: > >> Today building this toolchain with CMake is impossible because you cannot configure the cross-compiled builtins. The failure is a result of CMake’s try_compile function always testing a full compile then link operation. When bootstrapping a cross-compiler this will always fail because

On 3 October 2014 15:20, Evgeniy Stepanov <eugenis at google.com> wrote: > That's a third option. This flag only really makes sense for one or > several test cases in a large GTest file. They can be split and moved > to X86. But this adds more complexity to build system which, in my > opinion, is never good. Roger. > Compiler-rt and llvm build systems know very little

We had this discussion a few months ago and it petered out, and it’s recently been revived in the context of upgrading the CMake version specifically for libc++ (at which point people suggested upgrading the CMake version used by all of LLVM), so let’s try to move this forward. Our current required minimum version is CMake 3.4.3, which was released on January 25th 2016. It’s interesting to note

On Thu, Mar 26, 2020 at 11:48 PM Nikita Popov via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Thu, Mar 26, 2020 at 9:07 PM Shoaib Meenai via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> We had this discussion a few months ago and it petered out, and it’s recently been revived in the context of upgrading the CMake version specifically for libc++ (at which

> On 18 Nov 2019, at 22:11, Peter Smith <peter.smith at linaro.org> wrote: > > On Mon, 18 Nov 2019 at 17:06, Sergej Jaskiewicz <jaskiewiczs at icloud.com <mailto:jaskiewiczs at icloud.com>> wrote: >> >> >> >> On 18 Nov 2019, at 19:55, Peter Smith <peter.smith at linaro.org> wrote: >> >> On Mon, 18 Nov 2019 at 15:23, Sergej

> On Nov 2, 2015, at 11:41 AM, Vasileios Kalintiris <Vasileios.Kalintiris at imgtec.com> wrote: > >> The problem comes when bootstrapping a cross-compiler toolchain. In order to >> have a cross-compiling toolchain that can build a “hello world” application you >> need four basic components: >> >> (1) clang >> (2) ld >> (3) libclang_rt

Assuming this is a one-time version bump, this seems reasonable to me. Perhaps this goes without saying, but the warning for point 1 should only happen if you don’t have CMake >= 3.13.4 installed. It sounded to me from your original message that you have an urgent need to upgrade to 3.8. Were you planning on going ahead with that right away? From: llvm-dev <llvm-dev-bounces at

I’m in favor of all this. Thanks for volunteering! I’m happy to help out in whatever way. Some things it might be worth figuring out for future upgrades: * If we want to limit ourselves to CMake versions supported by LTS releases of distros, which distros should we consider, and how far back should we go (i.e. is it just the latest LTS or the last two LTS versions)? * For platforms like Ubuntu

Ubuntu 20.04 LTS will be released soon, and I believe it’ll have CMake 3.16.3, so that increases the LTS lower bound significantly. I strongly disagree with the sentiment that the build system already works so there’s no urgent need to improve it. I believe we should treat the build system like code, and the same ideas around refactoring apply. Our build system is a huge thorny mess; there’s tons

On 6/1/15 6:42 PM, Chris Bieneman wrote: > Looping in cfe-dev because I should have send this there too from the > start. > > -Chris > >> On Jun 1, 2015, at 3:21 PM, Chris Bieneman <beanz at apple.com> >> wrote: >> >> LLVMDev, >> >> PR 15732 is the umbrella tracking the progress of making the CMake >> build system feature equivalent to

> Why does fork-exec for llvm-symbolizer work, but simple exec(self) does not? Because the llvm-symbolizer the runtime finds is built for the host architecture. This is weird, yes, but once we integrate the symbolizer, it goes away. > Could we write a ulimit-like utility that would do setrlimit and then > exec the specified binary > %run %ulimit -s 8192 %t? I like that idea. How

> On Apr 2, 2020, at 10:19, Louis Dionne via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Okay, so we've had some discussion on this thread, and although some people (including me) would like a more aggressive policy, I believe the following will not get any objection (based on the thread). On April 23rd 2020, Ubuntu 20.04 LTS will ship with CMake 3.16.x. This will make the

'Supported' means that it comes from the packages available from the distribution that can be seen via this page. https://packages.ubuntu.com/ These packages have been processed by the Ubuntu community to obtain a reliability expectation that would not apply, for example, to a PPA. The difference between installing or building Clang and LLVM from original sources as against

Every additional dependency that we force the user to manually install (either by building from source, or adding some new PPA to their ubuntu system), raises the barrier to entry that much higher. Just because we may require the user to manually install some newer compiler on their system doesn’t mean that we should also require them to install some newer CMake than what’s on their system.

> You're saying "doesn’t mean that we should" while I've been saying in this situation that "we can", there is quite a difference here I believe. Technically “we can” do anything we want. We can always require that the project be built with the current release candidate of CMake. That doesn’t mean that we should. From: Mehdi AMINI <joker.eph at gmail.com>

I think it does make a difference how many things we ask new developers to do to get up and running - because we've asked them to do one thing doesn't mean it's low-cost to ask them to do another thing. On Tue, Apr 7, 2020 at 11:20 AM Mehdi AMINI via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Tue, Apr 7, 2020 at 9:16 AM Chris Tetreault <ctetreau at