bug-lilypond
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lilypond-2.17.28 doesn't build with libc++


From: David Kastrup
Subject: Re: lilypond-2.17.28 doesn't build with libc++
Date: Fri, 08 Nov 2013 12:01:04 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

Thomas Klausner <address@hidden> writes:

> Hi!
>
> I've tried building lilypond-2.17.28 with libc++, the new standard c++
> library for use with llvm (http://libcxx.llvm.org/).
>
> I have a build failure I don't really know how to fix, it is:
>
> In file included from file-path.cc:21:
> In file included from ./include/file-path.hh:23:
> In file included from ./include/std-vector.hh:74:
> /usr/include/c++/vector:1371:12: error: calling a private constructor of 
> class 'std::__1::__wrap_iter<std::__1::basic_string<char> *>'
>     return iterator(__p);
>            ^
> /usr/include/c++/vector:1408:12: note: in instantiation of member function 
> 'std::__1::__flower_vector<std::__1::basic_string<char>,
>       std::__1::allocator<std::__1::basic_string<char> > >::__make_iter' 
> requested here
>     return __make_iter(this->__end_);
>            ^
> ./include/std-vector.hh:155:15: note: in instantiation of member function 
> 'std::__1::__flower_vector<std::__1::basic_string<char>,
>       std::__1::allocator<std::__1::basic_string<char> > >::end' requested 
> here
>   v.insert (v.end (), w.begin (), w.end ());
>               ^
> file-path.cc:52:3: note: in instantiation of function template specialization 
> 'concat<std::__1::basic_string<char> >' requested here
>   concat (dirs_, string_split (p, PATHSEP));
>   ^
> /usr/include/c++/iterator:1200:31: note: declared private here
>     _LIBCPP_INLINE_VISIBILITY __wrap_iter(iterator_type __x) _NOEXCEPT : 
> __i(__x) {}

Looks like a rather fundamental problem in the C++ library to me.  Note
that this is triggered by use of the template function

template<typename T>
void
concat (vector<T> &v, vector<T> const &w)
{
  v.insert (v.end (), w.begin (), w.end ());
}

Now C++11 could likely be using w.cbegin () and w.cend () as a bug fix,
but that does not exist in the C++ standards we still use, and besides,
this usage should _never_ _ever_ lead to those kind of error messages.
Report this to the clang developers.

-- 
David Kastrup



reply via email to

[Prev in Thread] Current Thread [Next in Thread]