public inbox for gentoo-user@lists.gentoo.org
 help / color / mirror / Atom feed
From: Sergei Trofimovich <slyfox@gentoo.org>
To: Alan Grimes <alonzotg@verizon.net>
Cc: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] GCC 10.1 SUCKS.
Date: Sun, 17 May 2020 19:01:04 +0100	[thread overview]
Message-ID: <20200517190104.3d5981a9@sf> (raw)
In-Reply-To: <00926be7-f89a-e46a-5533-86e16ee50251@verizon.net>

On Thu, 14 May 2020 11:15:59 -0400
Alan Grimes <alonzotg@verizon.net> 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...
> 
> 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...
> 
> Here are some highlights from the fails that I consider "hard fails":
> 
> Dependency of libreoffice: Libetonyek 
> 
> 
>  -I/usr/include/libxml2  -DNDEBUG -DLIBETONYEK_VISIBILITY
> -fvisibility=hidden -march=native -pipe -O3  -Wall -Wextra -Wshadow
> -pedantic -Weffc++ -c -o
> contexts/libetonyek_internal_la-IWORKLayoutElement.lo `test -f
> 'contexts/IWORKLayoutElement.cpp' || echo './'`context
> s/IWORKLayoutElement.cpp
> /bin/sh ../../libtool  --tag=CXX   --mode=compile
> x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I../.. 
> -DBOOST_SPIRIT_USE_PHOENIX_V3  -DLIBETONYEK_BUILD -I../../inc
> -I../../src/lib/contexts   -I/usr/include/libxml2
> -I/usr/include/mdds-1.5 -I/usr/include/librevenge-0.0
>  -I/usr/include/libxml2  -DNDEBUG -DLIBETONYEK_VISIBILITY
> -fvisibility=hidden -march=native -pipe -O3  -Wall -Wextra -Wshadow
> -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 ‘virtual bool
> libetonyek::NUM3Parser::parseDocument()’:
> NUM3Parser.cpp:46:8: error: ‘for_each’ is not a member of ‘std’
>    46 |   std::for_each(sheetListRefs.begin(), sheetListRefs.end(),
> std::bind(&NUM3Parser::parseSheet, this, std::placeholders::_1));
>       |        ^~~~~~~~

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.

-- 

  Sergei


      reply	other threads:[~2020-05-17 18:01 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <00926be7-f89a-e46a-5533-86e16ee50251.ref@verizon.net>
2020-05-14 15:15 ` [gentoo-user] GCC 10.1 SUCKS Alan Grimes
2020-05-17 18:01   ` Sergei Trofimovich [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200517190104.3d5981a9@sf \
    --to=slyfox@gentoo.org \
    --cc=alonzotg@verizon.net \
    --cc=gentoo-user@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox