On Tuesday, December 27, 2016 02:20:20 PM Dale wrote: > J. Roeleveld wrote: > > On December 27, 2016 6:55:31 PM GMT+01:00, Dale <rdalek1...@gmail.com> wrote: > >> Alan Grimes wrote: > >>> Holger Hoffstätte wrote: > >>>> ..indicates a mismatch in C++11 ABI which changed in gcc5. What > >> > >> happens is that one the > >> > >>>> dependencies of openimageio was built against the old C++11 > >> > >> std::string ABI (hence the > >> > >>>> link errors), and needs to be rebuilt. It looks to be "Imf" aka > >> > >> libIlmImf, > >> > >>>> whatever that is. Try to rebuild it with --oneshot and it should > >> > >> work. > >> > >>>> If a similar error pops up for a different dependency, repeat. :) > >>>> > >>>> -h > >>> > >>> Yeah, I emptytree world my system after each Y in X.Y.Z compiler > >> > >> version > >> > >>> bump. Since I sad it, everyone will tell you it's bad advice but > >> > >> really > >> > >>> not. The binary distros will compile everything with the same > >> > >> compiler > >> > >>> so crap doesn't happen. Now it's not super important but then you > >> > >> have > >> > >>> no idea how many other abi link errors are hiding out there. > >> > >> I do the same here. When I switch to a new version of gcc, I do a > >> emerge -e world. If I've read that it really changes some things, like > >> this one appears to do, I do it twice. The second time may be overkill > >> but I'd rather have overkill than some weird problem that is difficult > >> to figure out the solution. I don't think anyone would say doing that > >> is bad. A ounce of prevention is always better than a pound of cure. > >> ;-) > >> > >> There's another upgrade that I do that after too. I can't recall the > >> name right now but maybe it is glibc or something???? > >> > >> Dale > >> > >> :-) :-) > > > > I usually do (if encountering weird issues): > > # emerge -1 gcc > > # emerge -1 glibc > > # emerge -e @system > > # emerge -e @world > > > > If there is a better method requiring less time, please let me know. > > > > A full rebuild like this into binary packages using a chroot is a good way > > to prepare for a toolchain update. That way all the packages are already > > prepared and the downtime will be minimized. > > > > -- > > Joost > > Giving it some thought, I would think your way would be the fastest. > When you emerge -e system, that should rebuild everything toolchain > wise. Then when you go back and do world, that should rebuild > everything with the new toolchain. I have ran emerge -e world twice in > the past but that requires more time than your way. Your way should > guarantee success and be the quickest.
There is a way that might even be quicker: - Temporarily switch to the most basic profile (desktop-profiles have a lot of additional USE-flags causing extra stuff in the @system set) - Temporarily move all "package.use" entries out of the way After "emerge -e @system" reset the correct profile and move all your package.use flags back. > I might add, in the past when I run into something weird, even with no > gcc or glibc changes, I would do a emerge -e world. Sometimes there can > be a change that doesn't get picked up on by emerge or even the devs. > Even the logs from a build failure may not give any real clue. That > said, it has been a while since I've had that sort of problem. I run a > mix of unstable and stable and still have a pretty sane system. I think > that says a lot about how portage/emerge/etc does its job now. The devs > have really worked out some serious kinks. I don't often have to do an "emerge -e" either. Only when something "important" changes. Like a profile, kde -> plasma, major gcc/glibc-version or similar. Can't really remember the last time, apart from when I updated my parents laptop after nearly 2 years in one go. (binaries compiled on a fast machine really helped there) The laptop functions as a simple media-player. > Now that I said that, something will come along pretty soon and just > bork everything up. LOL Tempting murphy? -- Joost
