1 |
On Tuesday, December 27, 2016 02:20:20 PM Dale wrote: |
2 |
> J. Roeleveld wrote: |
3 |
> > On December 27, 2016 6:55:31 PM GMT+01:00, Dale <rdalek1967@×××××.com> |
4 |
wrote: |
5 |
> >> Alan Grimes wrote: |
6 |
> >>> Holger Hoffstätte wrote: |
7 |
> >>>> ..indicates a mismatch in C++11 ABI which changed in gcc5. What |
8 |
> >> |
9 |
> >> happens is that one the |
10 |
> >> |
11 |
> >>>> dependencies of openimageio was built against the old C++11 |
12 |
> >> |
13 |
> >> std::string ABI (hence the |
14 |
> >> |
15 |
> >>>> link errors), and needs to be rebuilt. It looks to be "Imf" aka |
16 |
> >> |
17 |
> >> libIlmImf, |
18 |
> >> |
19 |
> >>>> whatever that is. Try to rebuild it with --oneshot and it should |
20 |
> >> |
21 |
> >> work. |
22 |
> >> |
23 |
> >>>> If a similar error pops up for a different dependency, repeat. :) |
24 |
> >>>> |
25 |
> >>>> -h |
26 |
> >>> |
27 |
> >>> Yeah, I emptytree world my system after each Y in X.Y.Z compiler |
28 |
> >> |
29 |
> >> version |
30 |
> >> |
31 |
> >>> bump. Since I sad it, everyone will tell you it's bad advice but |
32 |
> >> |
33 |
> >> really |
34 |
> >> |
35 |
> >>> not. The binary distros will compile everything with the same |
36 |
> >> |
37 |
> >> compiler |
38 |
> >> |
39 |
> >>> so crap doesn't happen. Now it's not super important but then you |
40 |
> >> |
41 |
> >> have |
42 |
> >> |
43 |
> >>> no idea how many other abi link errors are hiding out there. |
44 |
> >> |
45 |
> >> I do the same here. When I switch to a new version of gcc, I do a |
46 |
> >> emerge -e world. If I've read that it really changes some things, like |
47 |
> >> this one appears to do, I do it twice. The second time may be overkill |
48 |
> >> but I'd rather have overkill than some weird problem that is difficult |
49 |
> >> to figure out the solution. I don't think anyone would say doing that |
50 |
> >> is bad. A ounce of prevention is always better than a pound of cure. |
51 |
> >> ;-) |
52 |
> >> |
53 |
> >> There's another upgrade that I do that after too. I can't recall the |
54 |
> >> name right now but maybe it is glibc or something???? |
55 |
> >> |
56 |
> >> Dale |
57 |
> >> |
58 |
> >> :-) :-) |
59 |
> > |
60 |
> > I usually do (if encountering weird issues): |
61 |
> > # emerge -1 gcc |
62 |
> > # emerge -1 glibc |
63 |
> > # emerge -e @system |
64 |
> > # emerge -e @world |
65 |
> > |
66 |
> > If there is a better method requiring less time, please let me know. |
67 |
> > |
68 |
> > A full rebuild like this into binary packages using a chroot is a good way |
69 |
> > to prepare for a toolchain update. That way all the packages are already |
70 |
> > prepared and the downtime will be minimized. |
71 |
> > |
72 |
> > -- |
73 |
> > Joost |
74 |
> |
75 |
> Giving it some thought, I would think your way would be the fastest. |
76 |
> When you emerge -e system, that should rebuild everything toolchain |
77 |
> wise. Then when you go back and do world, that should rebuild |
78 |
> everything with the new toolchain. I have ran emerge -e world twice in |
79 |
> the past but that requires more time than your way. Your way should |
80 |
> guarantee success and be the quickest. |
81 |
|
82 |
There is a way that might even be quicker: |
83 |
- Temporarily switch to the most basic profile (desktop-profiles have a lot of |
84 |
additional USE-flags causing extra stuff in the @system set) |
85 |
- Temporarily move all "package.use" entries out of the way |
86 |
|
87 |
After "emerge -e @system" reset the correct profile and move all your |
88 |
package.use flags back. |
89 |
|
90 |
> I might add, in the past when I run into something weird, even with no |
91 |
> gcc or glibc changes, I would do a emerge -e world. Sometimes there can |
92 |
> be a change that doesn't get picked up on by emerge or even the devs. |
93 |
> Even the logs from a build failure may not give any real clue. That |
94 |
> said, it has been a while since I've had that sort of problem. I run a |
95 |
> mix of unstable and stable and still have a pretty sane system. I think |
96 |
> that says a lot about how portage/emerge/etc does its job now. The devs |
97 |
> have really worked out some serious kinks. |
98 |
|
99 |
I don't often have to do an "emerge -e" either. Only when something |
100 |
"important" changes. Like a profile, kde -> plasma, major gcc/glibc-version or |
101 |
similar. |
102 |
Can't really remember the last time, apart from when I updated my parents |
103 |
laptop after nearly 2 years in one go. (binaries compiled on a fast machine |
104 |
really helped there) |
105 |
The laptop functions as a simple media-player. |
106 |
|
107 |
> Now that I said that, something will come along pretty soon and just |
108 |
> bork everything up. LOL |
109 |
|
110 |
Tempting murphy? |
111 |
|
112 |
-- |
113 |
Joost |