from audiofx_lv2.h:11, from eca-object-factory.cpp:51: /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/include/g++-v11/bits/c++0x_warning.h:32:2: error: #error This file requires compiler and library support for the ISO C++ 2011 standard. This support must be enabled with the -std=c++11 or -std=gnu++11 compiler options. 32 | #error This file requires compiler and library support \ | ^~~~~ In file included from audiofx_lv2.h:11, from eca-object-factory.cpp:51: ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 17.1_no-multilib_hardened-20210427-181545 ------------------------------------------------------------------- gcc-config -l: [1] x86_64-pc-linux-gnu-7.3.1 [2] x86_64-pc-linux-gnu-11.1.0 * clang version 12.0.0 Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/lib/llvm/12/bin /usr/lib/llvm/12 12.0.0 Python 3.8.9 Available Ruby profiles: [1] ruby26 (with Rubygems) [2] ruby30 (with Rubygems) * Available Rust versions: [1] rust-bin-1.51.0 [2] rust-1.51.0 * The following VMs are available for generation-2: *) AdoptOpenJDK 8.292_p10 [openjdk-bin-8] Available Java Virtual Machines: [1] openjdk-bin-8 system-vm The Glorious Glasgow Haskell Compilation System, version 8.10.4 timestamp(s) of HEAD at this tinderbox image: /var/db/repos/gentoo Sun May 2 00:35:10 UTC 2021 emerge -qpvO media-sound/ecasound [ebuild N ] media-sound/ecasound-2.9.3 USE="lv2 ncurses oil -alsa -audiofile -debug -doc -jack -libsamplerate -mikmod -osc -oss -python -ruby -sndfile -static-libs -test" PYTHON_SINGLE_TARGET="python3_8 -python3_7 -python3_9"
Created attachment 705213 [details] emerge-info.txt
Created attachment 705216 [details] emerge-history.txt
Created attachment 705219 [details] environment
Created attachment 705222 [details] etc.portage.tar.bz2
Created attachment 705225 [details] logs.tar.bz2
Created attachment 705228 [details] media-sound:ecasound-2.9.3:20210502-061619.log
Created attachment 705231 [details] temp.tar.bz2
Ping
Created attachment 739842 [details, diff] build-with-std-c-11.patch NOTE: I used ed because a) I was too lazy to make a patch for such a trivial change b) sed is poorly suited to monkey patching, given that it is quite prepared to do nothing successfully (and expensively). By contrast, ed will complain if it is unable to mark the line to be edited or if it is unable to apply the substitution. Further, it will exit non-zero in either of these cases.
(In reply to Kerin Millar from comment #9) > Created attachment 739842 [details, diff] [details, diff] > build-with-std-c-11.patch > > NOTE: I used ed because a) I was too lazy to make a patch for such a trivial > change b) sed is poorly suited to monkey patching, given that it is quite > prepared to do nothing successfully (and expensively). By contrast, ed will > complain if it is unable to mark the line to be edited or if it is unable to > apply the substitution. Further, it will exit non-zero in either of these > cases. I don't love dragging in sys-apps/ed, but it's tiny, and I have it anyway, so meh. Calculating dependencies... done! sys-apps/ed-1.17 pulled in by: app-text/texlive-core-2021-r1 requires sys-apps/ed I'm actually impressed that ed does that. Maybe it's a good substitute for sed in some cases then.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=cf2415df1ebc1296ae6e59dc58f3c08d297b79ab commit cf2415df1ebc1296ae6e59dc58f3c08d297b79ab Author: Kerin Millar <kfm@plushkava.net> AuthorDate: 2021-09-19 05:24:25 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-09-19 05:42:40 +0000 media-sound/ecasound: build with -std=c++11 To specify the c++98 dialect is no longer compatible with lilv. Closes: https://bugs.gentoo.org/751583 Closes: https://bugs.gentoo.org/787620 Signed-off-by: Kerin Millar <kfm@plushkava.net> Signed-off-by: Sam James <sam@gentoo.org> media-sound/ecasound/ecasound-2.9.3.ebuild | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
(In reply to Sam James from comment #10) > I'm actually impressed that ed does that. Maybe it's a good substitute for > sed in some cases then. In virtually every case, I'd say (I was only scratching the surface as to why). Not to mention that the employed syntax tends towards being 100% portable. Linux people - for want of a better term - constantly employ GNUisms with sed. In my experience, it is not because they are consciously doing so, but because they have never read the specification or don't really know their tools. The real trouble with ed is that trying to persuade Linux vendors to ship it in its capacity as a standard utility is like trying to get blood out of a stone. They either don't get it or don't care.
