Doing an emerge -e @world (which I interrupted and resumed for a reboot) I just noticed my portage did this: >>> Emerging (1175 of 2305) media-plugins/gst-plugins-taglib-0.10.31-r1::gentoo >>> Emerging (1176 of 2305) sys-devel/gcc-5.3.0::gentoo >>> Installing (1175 of 2305) media-plugins/gst-plugins-taglib-0.10.31-r1::gentoo Specifically, it seems that media-plugins/gst-plugins-taglib-0.10.31-r1 was installed while sys-devel/gcc was still building. That's kinda gross. In this particular case, I think it's very unlikely to have caused any kind of real-world trouble, but gcc (in general, but especially, I have noticed, gcc-5.x), is extremely sensitive to the manipulation of header files while it runs. Even tiny trivial changes to header files that have absolutely nothing to do with gcc can cause gcc's header-scrubbing robot to freak out and abort the build. Maybe, worse things are possible than that -- I don't know what all that header scrubbing is for, so I couldn't say. Come to think of it, I'm not aware of any actual ebuild-level means to tell portage /not/ to parallelize something. No clue how to fix this or if it even should be fixed. But I thought it was worth mentioning. [note to bug wranglers: I seem to recall a rule and/or goal that portage was not supposed to parallelize builds in @system; if that's right, then probably this is a true implementation bug -- by which I mean, there is presumably code, somewhere in portage, meant to achieve this outcome of non-parallelization, but it fails to achieve it. Alternatively, maybe I'm just making that up (mis-remembering), or maybe it used to be true, but now it isn't, or whatever... in which case, I guess this is more like an "Enhancement/Feature Request"]
(In reply to Greg Turner from comment #0) > Specifically, it seems that media-plugins/gst-plugins-taglib-0.10.31-r1 was > installed while sys-devel/gcc was still building. > > That's kinda gross. In this particular case, I think it's very unlikely to > have caused any kind of real-world trouble, but gcc (in general, but > especially, I have noticed, gcc-5.x), is extremely sensitive to the > manipulation of header files while it runs. Even header files that are not among provided by gcc's dependencies? > Even tiny trivial changes to > header files that have absolutely nothing to do with gcc can cause gcc's > header-scrubbing robot to freak out and abort the build. Maybe, worse > things are possible than that -- I don't know what all that header scrubbing > is for, so I couldn't say. We'll need some kind of ebuild metadata to express this relationship. Perhaps a special type of blocker atom. > Come to think of it, I'm not aware of any actual ebuild-level means to tell > portage /not/ to parallelize something. No clue how to fix this or if it > even should be fixed. But I thought it was worth mentioning. Dependencies are currently the only way to specify that (think of it like parallel make). > [note to bug wranglers: I seem to recall a rule and/or goal that portage was > not supposed to parallelize builds in @system; if that's right, then > probably this is a true implementation bug -- by which I mean, there is > presumably code, somewhere in portage, meant to achieve this outcome of > non-parallelization, but it fails to achieve it. The special @system parallization code only places restrictions on when system packages are actually merged/installe (which is separate from the build step).
(In reply to Zac Medico from comment #1) > (In reply to Greg Turner from comment #0) > > Specifically, it seems that media-plugins/gst-plugins-taglib-0.10.31-r1 was > > installed while sys-devel/gcc was still building. > > > > That's kinda gross. In this particular case, I think it's very unlikely to > > have caused any kind of real-world trouble, but gcc (in general, but > > especially, I have noticed, gcc-5.x), is extremely sensitive to the > > manipulation of header files while it runs. > > Even header files that are not among provided by gcc's dependencies? Oh yeah. For sure. I think they go through everything in /usr/include indiscriminately as a first pass and "do things" based on various criteria... http://ewontfix.com/12 seems to confirm this -- it's some kind of dusting-under-the-carpet Rhoomba. > > Even tiny trivial changes to > > header files that have absolutely nothing to do with gcc can cause gcc's > > header-scrubbing robot to freak out and abort the build. Maybe, worse > > things are possible than that -- I don't know what all that header scrubbing > > is for, so I couldn't say. > > We'll need some kind of ebuild metadata to express this relationship. > Perhaps a special type of blocker atom. BDEPEND="@world"? :) just kidding, mostly. In all seriousness, though, there is nothing I can think of in the PMS that would enable us to fix this problem. If that's right then its simply a choice between 1) ignore it 2) put some hack into portage; goto 1 3) extend PMS somehow
I'm closing. It's not super reproducible, probably an upstream bug, and I don't think I've seen this problem with gcc's older than major 6... even if technically valid, I think this is the type of thing that will just linger for ten years and be forgotten, cluttering up bgo with little chance of being resolved and low importance/impact.
