From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id A410C1382C5 for ; Sun, 17 May 2020 18:01:14 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 4CB7AE08FB; Sun, 17 May 2020 18:01:10 +0000 (UTC) Received: from smtp.gentoo.org (woodpecker.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id C5918E08BD for ; Sun, 17 May 2020 18:01:09 +0000 (UTC) Date: Sun, 17 May 2020 19:01:04 +0100 From: Sergei Trofimovich To: Alan Grimes Cc: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] GCC 10.1 SUCKS. Message-ID: <20200517190104.3d5981a9@sf> In-Reply-To: <00926be7-f89a-e46a-5533-86e16ee50251@verizon.net> References: <00926be7-f89a-e46a-5533-86e16ee50251.ref@verizon.net> <00926be7-f89a-e46a-5533-86e16ee50251@verizon.net> X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; x86_64-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: d8f8a22d-94f8-4d61-9543-fd1f53d6fda1 X-Archives-Hash: 0b0b8847d9ee31b683b97ad64e82e97d On Thu, 14 May 2020 11:15:59 -0400 Alan Grimes wrote: > KDE really can't update itself, I really had to flog the living bleep > out of it to get it, and a lot of other stuff to settle down... >=20 > The configure phases for most of these packages are so monsterously > inefficient that I have to run dozens of builds concurently to get CPU > utilization out of the single digits... Okay, I have a high-end > processor rn but it's crazy watching the actual compile stages of > various packages only blip the histogram for a fraction of a second... >=20 > Here are some highlights from the fails that I consider "hard fails": >=20 > Dependency of libreoffice: Libetonyek=C2=A0 >=20 >=20 > =C2=A0-I/usr/include/libxml2=C2=A0 -DNDEBUG -DLIBETONYEK_VISIBILITY > -fvisibility=3Dhidden -march=3Dnative -pipe -O3=C2=A0 -Wall -Wextra -Wsha= dow > -pedantic -Weffc++ -c -o > contexts/libetonyek_internal_la-IWORKLayoutElement.lo `test -f > 'contexts/IWORKLayoutElement.cpp' || echo './'`context > s/IWORKLayoutElement.cpp > /bin/sh ../../libtool=C2=A0 --tag=3DCXX=C2=A0=C2=A0 --mode=3Dcompile > x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I../..=C2=A0 > -DBOOST_SPIRIT_USE_PHOENIX_V3=C2=A0 -DLIBETONYEK_BUILD -I../../inc > -I../../src/lib/contexts=C2=A0=C2=A0 -I/usr/include/libxml2 > -I/usr/include/mdds-1.5 -I/usr/include/librevenge-0.0 > =C2=A0-I/usr/include/libxml2=C2=A0 -DNDEBUG -DLIBETONYEK_VISIBILITY > -fvisibility=3Dhidden -march=3Dnative -pipe -O3=C2=A0 -Wall -Wextra -Wsha= dow > -pedantic -Weffc++ -c -o > contexts/libetonyek_internal_la-IWORKLineElement.lo `test -f > 'contexts/IWORKLineElement.cpp' || echo './'`contexts/IW > ORKLineElement.cpp > NUM3Parser.cpp: In member function =E2=80=98virtual bool > libetonyek::NUM3Parser::parseDocument()=E2=80=99: > NUM3Parser.cpp:46:8: error: =E2=80=98for_each=E2=80=99 is not a member of= =E2=80=98std=E2=80=99 > =C2=A0=C2=A0 46 |=C2=A0=C2=A0 std::for_each(sheetListRefs.begin(), sheetL= istRefs.end(), > std::bind(&NUM3Parser::parseSheet, this, std::placeholders::_1)); > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 ^~~~~~~~ Please file bugs to bugs.gentoo.org and maintainer should help you. In this case it looks like a https://bugs.gentoo.org/722042 which was a boost update. --=20 Sergei