| 1 |
J. Roeleveld wrote: |
| 2 |
> On December 27, 2016 6:55:31 PM GMT+01:00, Dale <rdalek1967@×××××.com> wrote: |
| 3 |
>> Alan Grimes wrote: |
| 4 |
>>> Holger Hoffstätte wrote: |
| 5 |
>>>> ..indicates a mismatch in C++11 ABI which changed in gcc5. What |
| 6 |
>> happens is that one the |
| 7 |
>>>> dependencies of openimageio was built against the old C++11 |
| 8 |
>> std::string ABI (hence the |
| 9 |
>>>> link errors), and needs to be rebuilt. It looks to be "Imf" aka |
| 10 |
>> libIlmImf, |
| 11 |
>>>> whatever that is. Try to rebuild it with --oneshot and it should |
| 12 |
>> work. |
| 13 |
>>>> If a similar error pops up for a different dependency, repeat. :) |
| 14 |
>>>> |
| 15 |
>>>> -h |
| 16 |
>>> Yeah, I emptytree world my system after each Y in X.Y.Z compiler |
| 17 |
>> version |
| 18 |
>>> bump. Since I sad it, everyone will tell you it's bad advice but |
| 19 |
>> really |
| 20 |
>>> not. The binary distros will compile everything with the same |
| 21 |
>> compiler |
| 22 |
>>> so crap doesn't happen. Now it's not super important but then you |
| 23 |
>> have |
| 24 |
>>> no idea how many other abi link errors are hiding out there. |
| 25 |
>>> |
| 26 |
>>> |
| 27 |
>> I do the same here. When I switch to a new version of gcc, I do a |
| 28 |
>> emerge -e world. If I've read that it really changes some things, like |
| 29 |
>> this one appears to do, I do it twice. The second time may be overkill |
| 30 |
>> but I'd rather have overkill than some weird problem that is difficult |
| 31 |
>> to figure out the solution. I don't think anyone would say doing that |
| 32 |
>> is bad. A ounce of prevention is always better than a pound of cure. |
| 33 |
>> ;-) |
| 34 |
>> |
| 35 |
>> There's another upgrade that I do that after too. I can't recall the |
| 36 |
>> name right now but maybe it is glibc or something???? |
| 37 |
>> |
| 38 |
>> Dale |
| 39 |
>> |
| 40 |
>> :-) :-) |
| 41 |
> I usually do (if encountering weird issues): |
| 42 |
> # emerge -1 gcc |
| 43 |
> # emerge -1 glibc |
| 44 |
> # emerge -e @system |
| 45 |
> # emerge -e @world |
| 46 |
> |
| 47 |
> If there is a better method requiring less time, please let me know. |
| 48 |
> |
| 49 |
> 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. |
| 50 |
> |
| 51 |
> -- |
| 52 |
> Joost |
| 53 |
> |
| 54 |
> |
| 55 |
|
| 56 |
Giving it some thought, I would think your way would be the fastest. |
| 57 |
When you emerge -e system, that should rebuild everything toolchain |
| 58 |
wise. Then when you go back and do world, that should rebuild |
| 59 |
everything with the new toolchain. I have ran emerge -e world twice in |
| 60 |
the past but that requires more time than your way. Your way should |
| 61 |
guarantee success and be the quickest. |
| 62 |
|
| 63 |
I might add, in the past when I run into something weird, even with no |
| 64 |
gcc or glibc changes, I would do a emerge -e world. Sometimes there can |
| 65 |
be a change that doesn't get picked up on by emerge or even the devs. |
| 66 |
Even the logs from a build failure may not give any real clue. That |
| 67 |
said, it has been a while since I've had that sort of problem. I run a |
| 68 |
mix of unstable and stable and still have a pretty sane system. I think |
| 69 |
that says a lot about how portage/emerge/etc does its job now. The devs |
| 70 |
have really worked out some serious kinks. |
| 71 |
|
| 72 |
Now that I said that, something will come along pretty soon and just |
| 73 |
bork everything up. LOL |
| 74 |
|
| 75 |
Dale |
| 76 |
|
| 77 |
:-) :-) |
Archives