Chromium fails to build under dunfell due to no viable constructor in skia

[JMBDowning]

Hi, I am able to build chromium-x11up to and including meta-browser commit 633dbeecfe0db3e4ac9750d871ad213149728d26 under dunfell but no commits after that. I am following the instructions for dunfell builds in the README.md using nodejs 14.x and using dunfell-clang12 (also tried dunfell-clang14 to no effect). I am building for an SOC with an intel chipset using the corei7 tuning and am using a custom distro based on linux-yocto rather than a pocky-based distro if that is helpful/relevant.

The build fails in the do_compile step with the following error:

| ../../third_party/skia/src/sksl/ir/SkSLType.cpp:1042:50: error: no viable constructor or deduction guide for deduction of template arguments of 'vector'
|                                                  std::vector(fieldSpan.begin(), fieldSpan.end()),
|                                                  ^
| /usr/lib/gcc/x86_64-linux-gnu/7.5.0/../../../../include/c++/7.5.0/bits/stl_vector.h:295:7: note: candidate function template not viable: no known conversion from 'const SkSL::Type::Field *' to 'size_type' (aka 'unsigned long') for 1st argument
|       vector(size_type __n, const value_type& __value,
|       ^
| /usr/lib/gcc/x86_64-linux-gnu/7.5.0/../../../../include/c++/7.5.0/bits/stl_vector.h:283:7: note: candidate template ignored: couldn't infer template argument '_Tp'
|       vector(size_type __n, const allocator_type& __a = allocator_type())
|       ^
| /usr/lib/gcc/x86_64-linux-gnu/7.5.0/../../../../include/c++/7.5.0/bits/stl_vector.h:411:2: note: candidate template ignored: couldn't infer template argument '_Tp'
|         vector(_InputIterator __first, _InputIterator __last,
|         ^
| /usr/lib/gcc/x86_64-linux-gnu/7.5.0/../../../../include/c++/7.5.0/bits/stl_vector.h:348:7: note: candidate template ignored: could not match 'vector<_Tp, _Alloc>' against 'const SkSL::Type::Field *'
|       vector(const vector& __x, const allocator_type& __a)
|       ^
| /usr/lib/gcc/x86_64-linux-gnu/7.5.0/../../../../include/c++/7.5.0/bits/stl_vector.h:358:7: note: candidate template ignored: could not match 'vector<_Tp, _Alloc>' against 'const SkSL::Type::Field *'
|       vector(vector&& __rv, const allocator_type& __m)
|       ^
| /usr/lib/gcc/x86_64-linux-gnu/7.5.0/../../../../include/c++/7.5.0/bits/stl_vector.h:383:7: note: candidate template ignored: could not match 'initializer_list<type-parameter-0-0>' against 'const SkSL::Type::Field *'
|       vector(initializer_list<value_type> __l,
|       ^
| /usr/lib/gcc/x86_64-linux-gnu/7.5.0/../../../../include/c++/7.5.0/bits/stl_vector.h:270:7: note: candidate function template not viable: requires single argument '__a', but 2 arguments were provided
|       vector(const allocator_type& __a) _GLIBCXX_NOEXCEPT
|       ^
| /usr/lib/gcc/x86_64-linux-gnu/7.5.0/../../../../include/c++/7.5.0/bits/stl_vector.h:326:7: note: candidate function template not viable: requires single argument '__x', but 2 arguments were provided
|       vector(const vector& __x)
|       ^
| /usr/lib/gcc/x86_64-linux-gnu/7.5.0/../../../../include/c++/7.5.0/bits/stl_vector.h:344:7: note: candidate function template not viable: requires single argument '__x', but 2 arguments were provided
|       vector(vector&& __x) noexcept
|       ^
| /usr/lib/gcc/x86_64-linux-gnu/7.5.0/../../../../include/c++/7.5.0/bits/stl_vector.h:216:11: note: candidate function template not viable: requires 1 argument, but 2 were provided
|     class vector : protected _Vector_base<_Tp, _Alloc>
|           ^
| /usr/lib/gcc/x86_64-linux-gnu/7.5.0/../../../../include/c++/7.5.0/bits/stl_vector.h:259:7: note: candidate function template not viable: requires 0 arguments, but 2 were provided
|       vector()
|       ^
| In file included from ../../third_party/skia/src/sksl/ir/SkSLType.cpp:8:
| In file included from ../../third_party/skia/src/sksl/ir/SkSLType.h:11:
| In file included from ../../third_party/skia/include/core/SkSpan.h:12:
| In file included from ../../third_party/skia/include/private/base/SkSpan_impl.h:11:
| In file included from ../../third_party/skia/include/private/base/SkAssert.h:11:
| In file included from ../../third_party/skia/include/private/base/SkAPI.h:11:
| In file included from ../../third_party/skia/include/private/base/SkLoadUserConfig.h:23:
| In file included from ../../third_party/skia/../../skia/config/SkUserConfig.h:127:
| In file included from ../../skia/ext/skia_histogram.h:11:
| In file included from /usr/lib/gcc/x86_64-linux-gnu/7.5.0/../../../../include/c++/7.5.0/memory:80:
| /usr/lib/gcc/x86_64-linux-gnu/7.5.0/../../../../include/c++/7.5.0/bits/unique_ptr.h:821:34: error: no matching constructor for initialization of 'SkSL::StructType'
|     { return unique_ptr<_Tp>(new _Tp(std::forward<_Args>(__args)...)); }
|                                  ^   ~~~~~~~~~~~~~~~~~~~~~~~~~~~
| ../../third_party/skia/src/sksl/ir/SkSLType.cpp:1040:26: note: in instantiation of function template specialization 'std::make_unique<SkSL::StructType, const SkSL::Position &, const std::basic_string<char> &, vector, bool>' requested here
|                     std::make_unique<StructType>(this->fPosition,
|                          ^
| ../../third_party/skia/src/sksl/ir/SkSLType.cpp:511:5: note: candidate constructor not viable: no known conversion from 'vector' to 'std::vector<Field>' for 3rd argument
|     StructType(Position pos, std::string_view name, std::vector<Field> fields, bool interfaceBlock)
|     ^
| ../../third_party/skia/src/sksl/ir/SkSLType.cpp:507:7: note: candidate constructor (the implicit copy constructor) not viable: requires 1 argument, but 4 were provided
| class StructType final : public Type {
|       ^
| 2 errors generated.

Any suggestions or is there something I have missed?

Thanks

[MaxIhlenfeldt]

Is this error message from a build using dunfell-clang14? If not, is the error message the same for dunfell-clang14?

I'm asking because the error references a header from /usr/lib/gcc/x86_64-linux-gnu/7.5.0, which shouldn't happen when using dunfell-clang14.

[JMBDowning]

That log comes from build using the dunfell-clang14 branch but the error was identical for dunfell-clang12. However that does trigger an idea: I did a full clean of chromium between both builds but I am not sure that I did a full clean and rebuild of clang and your comment suggests to me that I should have done so. I will do a full rebuild of clang and see if that changes things when I clean and rebuild chromium.

[JMBDowning]

I have tested with a fully cleaned build of clang using the dunfell-clang14 branch and I am still seeing this problem.

I also looked at the meta-clang repo and I note that the dunfell-clang14 branch is actually identical to the dunfell-clang12 branch (https://github.com/kraj/meta-clang/compare/dunfell-clang12...dunfell-clang14) and does not appear to actually make clang 14 available. Setting PREFERRED_VERSION:clang = "14.%" in local.conf with the dunfell-clang14 branch results in a message that clang 14 is not available and it reverts to 12.

It looks like there is an open issue in the meta-clang repo to deal with this (https://github.com/kraj/meta-clang/issues/835) so perhaps this needs to wait until meta-clang gets support for clang 14 in dunfell.

[MaxIhlenfeldt]

I also looked at the meta-clang repo and I note that the dunfell-clang14 branch is actually identical to the dunfell-clang12 branch

Oh, right - we're still in the process of merging dunfell-clang14 to https://github.com/kraj/meta-clang, sorry for the confusion. It currently still lives in this fork: https://github.com/rakuco/meta-clang. The fork's dunfell-clang14 branch is somewhat experimental, but I think you could still try using it to see if it does fix this error. If so, you could subscribe to the issue you already linked and wait until it's merged.

[JMBDowning]

I can confirm that using the rakuco dunfell-clang14 branch does fix this issue so I shall wait for that branch to be merged. Thanks for all the help!