phosek added a comment.
I think we just ran into one such issue. We're using our own Clang that's
usually following tip-of-tree and we recently switched to C++17, but that
started failing on our macOS 10.12 bots with:
Undefined symbols for architecture x86_64:
"operator delete(void*, std::align_val_t)", referenced from:
_main in main.cpp.o
std::__1::__vector_base<std::__1::unique_ptr<fidl::SourceFile,
std::__1::default_delete<fidl::SourceFile> >,
std::__1::allocator<std::__1::unique_ptr<fidl::SourceFile,
std::__1::default_delete<fidl::SourceFile> > > >::~__vector_base() in main.cpp.o
std::__1::__vector_base<std::__1::unique_ptr<fidl::raw::UnionDeclaration,
std::__1::default_delete<fidl::raw::UnionDeclaration> >,
std::__1::allocator<std::__1::unique_ptr<fidl::raw::UnionDeclaration,
std::__1::default_delete<fidl::raw::UnionDeclaration> > > >::~__vector_base()
in main.cpp.o
std::__1::__vector_base<std::__1::unique_ptr<fidl::raw::UnionMember,
std::__1::default_delete<fidl::raw::UnionMember> >,
std::__1::allocator<std::__1::unique_ptr<fidl::raw::UnionMember,
std::__1::default_delete<fidl::raw::UnionMember> > > >::~__vector_base() in
main.cpp.o
std::__1::__vector_base<std::__1::unique_ptr<fidl::raw::Attribute,
std::__1::default_delete<fidl::raw::Attribute> >,
std::__1::allocator<std::__1::unique_ptr<fidl::raw::Attribute,
std::__1::default_delete<fidl::raw::Attribute> > > >::~__vector_base() in
main.cpp.o
std::__1::__vector_base<std::__1::unique_ptr<fidl::raw::StructDeclaration,
std::__1::default_delete<fidl::raw::StructDeclaration> >,
std::__1::allocator<std::__1::unique_ptr<fidl::raw::StructDeclaration,
std::__1::default_delete<fidl::raw::StructDeclaration> > > >::~__vector_base()
in main.cpp.o
std::__1::__vector_base<std::__1::unique_ptr<fidl::raw::StructMember,
std::__1::default_delete<fidl::raw::StructMember> >,
std::__1::allocator<std::__1::unique_ptr<fidl::raw::StructMember,
std::__1::default_delete<fidl::raw::StructMember> > > >::~__vector_base() in
main.cpp.o
...
"operator new(unsigned long, std::align_val_t)", referenced from:
std::__1::enable_if<__is_forward_iterator<char*>::value, void>::type
std::__1::basic_string<char, std::__1::char_traits<char>,
std::__1::allocator<char> >::__init<char*>(char*, char*) in main.cpp.o
std::__1::unique_ptr<std::__1::__tree_node<std::__1::__value_type<(anonymous
namespace)::Behavior, std::__1::basic_fstream<char, std::__1::char_traits<char>
> >, void*>,
std::__1::__tree_node_destructor<std::__1::allocator<std::__1::__tree_node<std::__1::__value_type<(anonymous
namespace)::Behavior, std::__1::basic_fstream<char,
std::__1::char_traits<char> > >, void*> > > >
std::__1::__tree<std::__1::__value_type<(anonymous namespace)::Behavior,
std::__1::basic_fstream<char, std::__1::char_traits<char> > >,
std::__1::__map_value_compare<(anonymous namespace)::Behavior,
std::__1::__value_type<(anonymous namespace)::Behavior,
std::__1::basic_fstream<char, std::__1::char_traits<char> > >,
std::__1::less<(anonymous namespace)::Behavior>, true>,
std::__1::allocator<std::__1::__value_type<(anonymous namespace)::Behavior,
std::__1::basic_fstream<char, std::__1::char_traits<char> > > >
>::__construct_node<(anonymous namespace)::Behavior,
std::__1::basic_fstream<char, std::__1::char_traits<char> > >((anonymous
namespace)::Behavior&&, std::__1::basic_fstream<char,
std::__1::char_traits<char> >&&) in main.cpp.o
std::__1::__split_buffer<fidl::SourceManager,
std::__1::allocator<fidl::SourceManager>&>::__split_buffer(unsigned long,
unsigned long, std::__1::allocator<fidl::SourceManager>&) in main.cpp.o
std::__1::vector<fidl::StringView,
std::__1::allocator<fidl::StringView> >::__vallocate(unsigned long) in
main.cpp.o
std::__1::unique_ptr<std::__1::__tree_node<std::__1::__value_type<std::__1::vector<fidl::StringView,
std::__1::allocator<fidl::StringView> >,
std::__1::unique_ptr<fidl::flat::Library,
std::__1::default_delete<fidl::flat::Library> > >, void*>,
std::__1::__tree_node_destructor<std::__1::allocator<std::__1::__tree_node<std::__1::__value_type<std::__1::vector<fidl::StringView,
std::__1::allocator<fidl::StringView> >,
std::__1::unique_ptr<fidl::flat::Library,
std::__1::default_delete<fidl::flat::Library> > >, void*> > > >
std::__1::__tree<std::__1::__value_type<std::__1::vector<fidl::StringView,
std::__1::allocator<fidl::StringView> >,
std::__1::unique_ptr<fidl::flat::Library,
std::__1::default_delete<fidl::flat::Library> > >,
std::__1::__map_value_compare<std::__1::vector<fidl::StringView,
std::__1::allocator<fidl::StringView> >,
std::__1::__value_type<std::__1::vector<fidl::StringView,
std::__1::allocator<fidl::StringView> >,
std::__1::unique_ptr<fidl::flat::Library,
std::__1::default_delete<fidl::flat::Library> > >,
std::__1::less<std::__1::vector<fidl::StringView,
std::__1::allocator<fidl::StringView> > >, true>,
std::__1::allocator<std::__1::__value_type<std::__1::vector<fidl::StringView,
std::__1::allocator<fidl::StringView> >,
std::__1::unique_ptr<fidl::flat::Library,
std::__1::default_delete<fidl::flat::Library> > > >
>::__construct_node<std::__1::pair<std::__1::vector<fidl::StringView,
std::__1::allocator<fidl::StringView> >,
std::__1::unique_ptr<fidl::flat::Library,
std::__1::default_delete<fidl::flat::Library> > >
>(std::__1::pair<std::__1::vector<fidl::StringView,
std::__1::allocator<fidl::StringView> >,
std::__1::unique_ptr<fidl::flat::Library,
std::__1::default_delete<fidl::flat::Library> > >&&) in main.cpp.o
std::__1::enable_if<__is_forward_iterator<char const*>::value,
void>::type std::__1::basic_string<char, std::__1::char_traits<char>,
std::__1::allocator<char> >::__init<char const*>(char const*, char const*) in
libfidl.a(c_generator.cpp.o)
std::__1::__split_buffer<unsigned int, std::__1::allocator<unsigned
int>&>::__split_buffer(unsigned long, unsigned long,
std::__1::allocator<unsigned int>&) in libfidl.a(c_generator.cpp.o)
...
ld: symbol(s) not found for architecture x86_64
AFAICT this is because `/usr/lib/libc++.dylib` doesn't yet support C++17, but
the headers that are part of Clang toolchain do. When we force Clang to use
libc++ that's part of the toolchain by manually setting the necessary `-L`/`-l`
flag resolves the issue. I don't know if this is an expected behavior, but I'd
really appreciate some response on this.
Repository:
rC Clang
https://reviews.llvm.org/D45639
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
