similar to: Patch depends on the previous storage patch...

define domain -> add virtual machine (addvm) undefine domain -> remove virtual machine (rmvm) create domain -> start virtual machine (startvm) destroy domain -> stop virtual machine (stopvm) list domains -> list virtual machiens (listvms) Signed-off-by: Darryl L. Pierce <dpierce at redhat.com> --- Makefile.am | 8 +- nodeadmin/adddomain.py |

This version of the patch includes feedback from jboggs at redhat.com, including fixes to the BuildRequires and Requires in the spec file.

This patch obsoletes any previous ones. This is an upstream candidate, so I'm looking for feedback so we can push this and start using it.

This version fixes a few bugs found by jboggs. It also includes some logging facilities that need to be fleshed out more.

This patch is ready for pushing upstream.

The previous patch was missing this file. Resending.

...just looking for some feedback on the direction I'm going. The code won't get all the way to the define stage since I'm in the middle of retrofitting it to use virtinst instead of a home spun node definition.

This pair of patches provide a new storage admin interface. Then, on top of that, it refactors the domain administration pieces to now properly use storage pools and volumes when defining a new VM.

This set of patches supercedes the previous set, and has been rebased with changes from upstream.

This patch again rebases on upstream and should apply on next as of right now.

This patch provides the ability to create a "dir" type storage pool, and to add and remove volumes for existing pools.

Moved the node administration elements to a separate submenu. Created a new network administration menu. * users can define a network * users can create a network * users can destroy a network * users can undefine a network * users can list existing networks, including details Each new command is also available as a separate command line executable as well. Signed-off-by: Darryl L. Pierce

I'm building LLVM with Clang, LLD, compiler-rt, libunwind, libcxx and libcxxabi. I'm using GCC 7.1.1 and binutils 2.28.0 to build. The compilation is aborted during libunwind build due to gcc not being able to parse libcxx's __config: /usr/bin/cc -DLLVM_BUILD_GLOBAL_ISEL -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Iprojects/libunwind/src

A recent change added defined(__linux__) condition to the code below. Now it says that on linux with --std=c++0x (or --std=c++11) the system stdlib.h header must define aligned_alloc(). Really? include/__config: #if ( defined(__FreeBSD__) || defined(__linux__) ) && (__ISO_C_VISIBLE >= 2011 || __cplusplus >= 201103L) #define _LIBCPP_HAS_QUICK_EXIT #define _LIBCPP_HAS_C11_FEATURES

Hi, On Mon, May 13, 2013 at 10:49 AM, Evgeniy Stepanov < eugeni.stepanov at gmail.com> wrote: > A recent change added defined(__linux__) condition to the code below. > Now it says that on linux with --std=c++0x (or --std=c++11) the system > stdlib.h header must define aligned_alloc(). Really? > > include/__config: > > #if ( defined(__FreeBSD__) || defined(__linux__) )

Most of libc++ doesn't have explicit template instantiations, which leads to a pretty significant build time and code size cost when using libc++, since a large number of common templates will be emitted by the compiler and coalesced by the linker. Notably, in include/__config, we have: #ifndef _LIBCPP_EXTERN_TEMPLATE #define _LIBCPP_EXTERN_TEMPLATE(...) #endif whereas before

On Tue, Dec 19, 2017 at 8:33 AM Jonathan Roelofs <jonathan at codesourcery.com> wrote: > On 12/19/17 9:15 AM, Petr Hosek via llvm-dev wrote: > > Today, there're two different locations for runtimes files within > > Clang's installation: > > > > compiler-rt: > > headers: $prefix/lib/clang/$version/include(/sanitizer) > > libraries: >

Today, there're two different locations for runtimes files within Clang's installation: compiler-rt: headers: $prefix/lib/clang/$version/include(/sanitizer) libraries: $prefix/lib/clang/$version/lib/$os/libclang_rt.$name-$arch.$ext libc++, libc++abi, libunwind: headers: $prefix/include/c++/v1 libraries: $prefix/lib/$name.$ext The scheme used by libc++, libc++abi, libunwind

Hi, I am trying to build llvm 3.4.2 on Centos 6.6. I am getting this below build error , while building the libcxx. I followed the build procedure based of http://clang.llvm.org/get_started.html. I cannot move to a higher version, Since we need to develop on CentOS 6.6 and LLVM 3.4.2 ,is the last version that supports gcc 3.4.2. Starting from LLVM 3.5.0, there has been a huge jump to gcc 4.7.0.

+eugenis I see this while running 'check-msan'. On Sun, May 12, 2013 at 9:10 PM, David Blaikie <dblaikie at gmail.com> wrote: > Is no one else seeing this? (I've been seeing it for a few days) > > In file included from > > /usr/local/google/home/blaikie/dev/llvm/src/utils/unittest/googletest/gtest-all.cc:39: > In file included from > >