src/common/libmtxcommon.a(ebml_chapters_converter.o): In function `mtx::xml::ebml_chapters_converter_c::fix_display(libmatroska::KaxChapterDisplay&) const': ebml_chapters_converter.cpp:(.text+0x33ef): undefined reference to `libebml::EbmlString::operator std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&() const' ebml_chapters_converter.cpp:(.text+0x35ec): undefined reference to `libebml::EbmlString::operator std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&() const' collect2: error: ld returned 1 exit status * ERROR: media-video/mkvtoolnix-18.0.0::gentoo failed (compile phase): ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 13.0_libressl_20171111-114143 ------------------------------------------------------------------- gcc-config -l: [1] x86_64-pc-linux-gnu-7.2.0 * Available Python interpreters, in order of preference: [1] python3.4 [2] python3.6 (fallback) [3] python2.7 (fallback) [4] pypy3 (fallback) [5] pypy (fallback) Available Ruby profiles: [1] ruby22 (with Rubygems) * emerge -qpv media-video/mkvtoolnix [ebuild N ] media-video/mkvtoolnix-18.0.0 USE="-debug -pch -qt5 {-test}"
Created attachment 505140 [details] emerge-info.txt
Created attachment 505142 [details] emerge-history.txt
Created attachment 505144 [details] environment
Created attachment 505146 [details] etc.portage.tbz2
Created attachment 505148 [details] logs.tbz2
Created attachment 505150 [details] media-video:mkvtoolnix-18.0.0:20171120-092659.log
Created attachment 505152 [details] temp.tbz2
Same here on ~amd64
I ran into this too, resolved it with: emerge -1av boost libebml I suspect boost was optional, but I just do boost anytime a C++ program fails to build and usually it resolves it.
Just re-emerging libebml worked here, thanks.
Just re-emerging libebml worked here too. I skipped to re-emerge whole world after last gcc-upgrade. That might be a reason...
Happens again with mkvtoolnix-19.0.0, and again the workaround is to emerge -1 libebml. However, what's really strange: I did remerge libebml after 18.0.0 did fail (otherwise I wouldn't be upgrading from 18.0.0 to 19.0.0). Yet it's again necessary to remerge libebml - why?
*** Bug 660498 has been marked as a duplicate of this bug. ***
*** Bug 660846 has been marked as a duplicate of this bug. ***
@toolchain, is there a way to catch packages affected by https://wiki.debian.org/GCC7#GCC_7_name_mangling_bug_fix ? Per https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=gcc-7-op-mangling;users=debian-gcc@lists.debian.org , more packages could be affected by this
*** Bug 660872 has been marked as a duplicate of this bug. ***
*** Bug 661294 has been marked as a duplicate of this bug. ***
*** Bug 662618 has been marked as a duplicate of this bug. ***
*** Bug 664068 has been marked as a duplicate of this bug. ***
*** Bug 665224 has been marked as a duplicate of this bug. ***
*** Bug 679378 has been marked as a duplicate of this bug. ***
Dependencies have to be rebuilt first to apply new default of -std=c++11 (or 14). There is no nice way to catch ABI skew at dependency resolution time.
