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. 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. Now that I said that, something will come along pretty soon and just bork everything up. LOL Dale :-) :-)
