similar to: [LLVMdev] zorg config for libc++/libc++abi

On 04/08/2014 16:20, Dmitri Gribenko wrote: > On Mon, Aug 4, 2014 at 2:20 PM, Dan Liew <dan at su-root.co.uk> wrote: >>>> Second, is there a simple way to test the builder and config before I >>>> commit >>>> it? >>> >>> I am afraid not. >>> >> >> But there is a ugly (and certainly not simple) way to partially test

> > Second, is there a simple way to test the builder and config before I commit > > it? > > I am afraid not. > But there is a ugly (and certainly not simple) way to partially test the builder that I mentioned recently [1]. I say partially because I ended up removing all the builders apart from my own. @Dmitri - Has anyone considered reorganising zorg so it is easier to

> Please go ahead. We can host the buildbot here: > > http://lab.llvm.org:8011/buildslaves/gribozavr4 Thanks. I guess I'll have to do some reading because I don't have a good high level understanding of how the build bot works. For gribozavr4 does that mean running a new buildbot slave process on the machine or can slaves build multiple configurations (is this the same as what

Hi Dmitri, Sorry it's taken so long for me to take a look at this. I've finally found some free time to look at this :) I've got created a factory for building Sphinx documentation on my local machine and that's mostly working so I plan to submit a patch soon. Can I check a few things with you? - Is it still okay to use 'gribozavr4' as the build slave? - The factory

On Fri, Jan 30, 2015 at 4:15 PM, Dan Albert <danalbert at google.com> wrote: > On Fri, Jan 30, 2015 at 4:12 PM, Saleem Abdulrasool <compnerd at compnerd.org > > wrote: > >> On Fri, Jan 30, 2015 at 3:35 PM, Dan Albert <danalbert at google.com> wrote: >> >>> Shouldn't it just use the default unwinder for the given platform? >>> >>

Hi, I've been spending a bit of time fixing up building and installation of the Doxygen and Sphinx documentation for CMake. There are more fixes in the pipeline (none for autconf/make system, I'm not interested in fixing that) but I started wondering if any testing was done to check that documentation builds correctly for LLVM and its various subprojects. I'm not particularly

On Fri, Jan 30, 2015 at 4:12 PM, Saleem Abdulrasool <compnerd at compnerd.org> wrote: > On Fri, Jan 30, 2015 at 3:35 PM, Dan Albert <danalbert at google.com> wrote: > >> Shouldn't it just use the default unwinder for the given platform? >> > > Sure, but what is the default unwinder for a given platform? > > Lets go with Linux. I have two different

Talked it over with Saleem on IRC, and I've come around to thinking libunwind is a better default for --rtlib=compiler-rt. Reason being that --rtlib=compiler-rt means libgcc probably isn't even available. On Fri, Jan 30, 2015 at 5:30 PM, Saleem Abdulrasool <compnerd at compnerd.org> wrote: > On Fri, Jan 30, 2015 at 4:15 PM, Dan Albert <danalbert at google.com> wrote: >

If your cut-n-paste is accurate, you seem to be missing a closing quote for CMAKE_CXX_LINK_FLAGS. hth... don On Jul 8, 2015 2:22 AM, "David A. Greene" <greened at obbligato.org> wrote: > greened at obbligato.org (David A. Greene) writes: > > > I looked at the instructions on the libc++ page and for Linux it > > recommends building with -stdlib=libc++ -lc++abi.

On Fri, Jan 30, 2015 at 3:35 PM, Dan Albert <danalbert at google.com> wrote: > On Fri, Jan 30, 2015 at 3:10 PM, Saleem Abdulrasool <compnerd at compnerd.org > > wrote: > >> On Fri, Jan 30, 2015 at 1:41 PM, Renato Golin <renato.golin at linaro.org> >> wrote: >> >>> What about the default unwinder for Compiler-RT? Should we assume our

On 31 Jan 2015, at 03:02, Dan Albert <danalbert at google.com> wrote: > > Talked it over with Saleem on IRC, and I've come around to thinking libunwind is a better default for --rtlib=compiler-rt. Reason being that --rtlib=compiler-rt means libgcc probably isn't even available. On FreeBSD, we install compiler-rt as libgcc (or, at least, symlink it to libgcc). This means that

Hi, The minimum CMake version currently advertised for libc++ and libc++abi is currently 3.4.3. I think the oldest version of CMake actually being tested on any builder is 3.7.0, so advertising 3.4.3 is somewhat of a lie (I'm pretty sure we're using features that require a more recent version already). However, we do need to bump it to 3.8.0 at least because CMake 3.7 doesn't know

Hi All, Recent conversations [1][2] would suggest we need to rethink zorg or at the very least improve the documentation. I've CC'ed Daniel Dunbar, Galina Kistanova and Duncan Sands because it seemed that they have contributed the most code to Zorg Organisation ========= The current organisation of the Zorg repository doesn't make a huge amount of sense from my perspective. There

On Fri, Feb 20, 2015 at 7:02 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > 2. We need to clarify how libstdc++ and libsupc++ can be used as > > libc++'s ABI library and explicitly define the level of support for > > these configurations. Are there any people using this functionality? > > These configurations have been broken for GCC >= 4.9.2 and I haven't

[Sorry about the crosspost. Since this is a clang build question but the build is invoked from the top-level LLVM directory I'm not sure where the question should go.] I've got a clang build against libstdc++ on Linux but I would really like one built against libc++/libc++abi. In other words I'd like to rebuild clang/llvm with clang using libc++ and libc++abi on Linux. I looked at

Hi Nick! In r207467 you added code(libunwind: DwarfInstructions.hpp): assert(lastReg <= (int)cieInfo.returnAddressRegister && "register range does not contain return address register"); for (int i = 0; i <= lastReg; ++i) { ..... else if (i == (int)cieInfo.returnAddressRegister) There is misprint here: lastReg should be >=

Hi All, Currently libc++ does not list linux as a supported platform. This should change. I think we should be able to list linux (with libc++abi) as a supported configuration. but there are some issues I would like to see resolved first. 1. We should add CMake support for building libc++ against a static libc++abi. If libc++ is linked to a shared libc++abi the resulting library can only be used

On 03/24/2020 09:00 PM, Petr Hosek via llvm-dev wrote: > In October, there was a discussion about updating CMake to 3.15: http://lists.llvm.org/pipermail/llvm-dev/2019-October/136295.html. No decision was made, but maybe we should revisit that proposal? If we're going to require a newer version of CMake for some subprojects, I'd prefer to bump the minimum CMake version for all of LLVM.

Hello everyone, Zorg is a common code for multiple different buildbot setups. This is why it sits in its own subtree. The only tricky thing there is that it assumes some relative position of zorg and master setup. Documenting this would save somebody some time. All together wasn't a problem so far. But having a better documentation and a set of files for a simple local setup is a good idea.

Galina, Looks like the build bots have frozen. Expected? Joe Joe Abbey Software Architect Arxan Technologies, Inc. 1305 Cumberland Ave, Ste 215 West Lafayette, IN 47906 jabbey at arxan.com<mailto:jabbey at arxan.com> www.arxan.com<http://www.arxan.com/> On Nov 18, 2011, at 11:49 AM, Galina Kistanova wrote: Author: gkistanova Date: Fri Nov 18 13:49:26 2011 New Revision: 144978