audacious-plugins fails with gcc 5

[audiodef]

Trying to compile audacious-plugins-3.7.1-r1 (or 3.7.1) after upgrading to gcc 5 ends like so:

[ct85711]

Now, how about giving us the full build.log so we can get the actual error message.

[audiodef]

That's actually the entire error message, but here is the build log.

emerge --info '=media-plugins/audacious-plugins-3.7.1-r1::gentoo':

[Jaglover]

The first thing I do troubleshooting issue like this is building with -j1, with multiple make instances running the log is messy.
_________________
My Gentoo installation notes.
Please learn how to denote units correctly!

[asturm]

[audiodef]

That was the actual build log.

I keep forgetting to try -j1 first, thanks for the reminder. Doing that, I get something more useful:

[asturm]

jack was rebuilt after your GCC-5 upgrade?

[audiodef]

Yup, still no dice. Had to switch to gcc 4 to get it to compile with jack.
_________________
decibel Linux: https://decibellinux.org
Github: https://github.com/Gentoo-Music-and-Audio-Technology
Facebook: https://www.facebook.com/decibellinux
Discord: https://discord.gg/73XV24dNPN

[Logicien]

One thing I remark is when you mixte dependancy packages amd64 with ~amd64 it may fail. Your using audacious-plugins-3.7.1-r1 and gcc-5? who are both ~amd64.

If you cannot reach the goal of compiling audacious-plugins with gcc ~amd64 (without disabling USE flags), it's just because you are working with unstable versions who are not ready for production and cannot expect to succeed unless you are a developper of those packages or have equivalent knowledge. This is my personnal opinion and approch with ~.
_________________
Paul

[Hu]

That looks to me like a bug exposed by cleanup on the gcc side. System headers often include other headers to satisfy prerequisites. Sometimes, the immediate header includes more than it needed. This may slow compilation, but does not harm correctness. However, if an application assumes that including <foo> will also include <bar> (because the currently released versions happen to work that way) and the standard does not guarantee that inclusion, then the owner of <foo> (in this case, gcc) may at some point change so that it no longer includes <bar>. In this case, it looks like audacious included headers that, under gcc-4.9, happened to include a definition of std::end for C arrays. Under gcc-5, that header is no longer included by gcc's headers, so audacious needs to specify the inclusion explicitly. Please patch that file to #include <iterator> among the other includes and try again.

[turtles]

[szamó]

Thank you for the simple, effective solution. I believe it is in the 3.7.1-r1 package now, although it is masked in my Gentoo.