1 |
Kyle Liddell <kyle@××××××××××××××××.net> posted |
2 |
20060706042949.GA24867@××××××.localdomain, excerpted below, on Wed, 05 |
3 |
Jul 2006 23:29:49 -0500: |
4 |
|
5 |
> On Wed, Jul 05, 2006 at 05:04:00PM +0000, Duncan wrote: |
6 |
>> Have you run fix_libtool_files.sh recently? I'm asking because I see |
7 |
>> the |
8 |
>> |
9 |
> I always forget to run that, but I did, and still no gmp. |
10 |
|
11 |
I didn't really expect it to, as those errors are usually rather |
12 |
different, but thought it was worth a shot. |
13 |
|
14 |
>> Do you routinely run your emerge --update with the --deep (-D) switch? |
15 |
> Always. |
16 |
|
17 |
Someone who thinks like me! =8^) I'd rather have them updated one at a |
18 |
time than find I need to update a whole bunch when say a new KDE comes out |
19 |
and I have 100-ish just KDE packages to update! While it does |
20 |
occasionally produce headaches, I'd rather have those headaches than |
21 |
trying to trace something that isn't working just because it's too old. |
22 |
|
23 |
So anyway, that's eliminated too... |
24 |
|
25 |
>> How much of your system has been recompiled with gcc-4.1.x? |
26 |
|
27 |
[reordered quote below a bit to make sense after snippage] |
28 |
> Ick, that's (almost) the same as a reinstall... |
29 |
> Umm...not much. If I could ever get gmp compiled, then I could get |
30 |
> around to compiling a good chunk of the rest... |
31 |
> |
32 |
> However, I have built/rebuilt/rebuilt again gcc, glibc, and binutils |
33 |
> with gcc 4.1.1. |
34 |
|
35 |
The gcc upgrade guide (http://www.gentoo.org/doc/en/gcc-upgrading.xml) |
36 |
suggests an emerge -e system followed by emerge -e world, which would |
37 |
actually recompile the entire system twice, once for each command. |
38 |
Certainly, I can see that for at minimum gcc, since the first time it's |
39 |
built it will be with the old version, so a second gcc rebuild is necessary |
40 |
to have /everything/ compiled with it. However, for the non-toolchain |
41 |
parts of system IMO that's a bit overboard. Still, since there's no |
42 |
"tool-chain" target, that does keep the instructions simpler than having |
43 |
to list each bit of the toolchain separately. |
44 |
|
45 |
Personally, I think it's a bit overboard to run an emerge --emptytree |
46 |
world anyway, in most cases for ~arch anyway, since it upgrades more |
47 |
frequently. There'd be the occasional exception (like the special-cases |
48 |
in the upgrade guide), but I don't think it needs done every time. Stable |
49 |
is a bit more iffy, since they don't get the benefit of the intermediate |
50 |
upgrades that ~arch usually does. I guess I can see the argument being |
51 |
made for them, which of course means it's made for everyone since stable |
52 |
is intended to be the arch default. |
53 |
|
54 |
That said, I'd not be /too/ worried about it in general, but certainly, |
55 |
when strange errors start occurring shortly after a gcc upgrade, it's a |
56 |
good troubleshooting step if the process was previously skipped. |
57 |
|
58 |
Again, I've personally been running far more intermediate steps, unmasking |
59 |
and making system default 4.0.0, 4.0.1, 4.0.2, 4.0.3, and 4.1.0 in turn as |
60 |
they came available. It /is/ quite a big jump from 3.4.6 to 4.1.1, but I |
61 |
didn't do it all at once as those running ~arch that didn't unmask along |
62 |
the way will have done. Actually, that emerge --emptytree that I did |
63 |
along the way wasn't necessary AFAIK. I just did it after upgrading to 8 |
64 |
gig of memory and setting $PORTAGE_TMPDIR to a tmpfs, mainly to test my |
65 |
hardware, but also to see if all the previous issues with gcc-4.x on |
66 |
specific packages had been fixed, as well as to just do an emerge |
67 |
--emptytree to say I'd done it, since I hadn't before that and I wanted to |
68 |
try it. |
69 |
|
70 |
Anyway, like I said, I'd not go as far as the upgrade guide and do it |
71 |
routinely for every gcc upgrade, but certainly, after moving from 3.4.x to |
72 |
4.1.x, if I experienced weird errors, I'd do it just to eliminate that as |
73 |
a possibility, which is what I'm saying here. |
74 |
|
75 |
|
76 |
>> Another possible difference... I run very little 32-bit at all |
77 |
> |
78 |
> And oh yeah, I tried emerge'ing with -sandbox. Same deal. |
79 |
|
80 |
Oh yeah, I was going to mention that but forgot. You're ahead of me on |
81 |
that! =8^) |
82 |
|
83 |
> About all I have 32bit-wise is enough to get a flash plugin for |
84 |
> firefox-bin. I have thought that multilib was a bit messy though, and I |
85 |
> might try dumping it since most of my 32bit stuff only works in a |
86 |
> chroot'd system (ISE, wine, etc). But as for this exact problem, I |
87 |
> don't really see anything that is safe to delete/move/hide that is |
88 |
> definitely 32bit only that could be making problems. |
89 |
|
90 |
The possible problem would be the configure for some reason pointing at |
91 |
the 32-bit lib. Since this isn't a 32-bit compile, as long as you don't |
92 |
run any 32-bit programs while doing it, you should have no issues |
93 |
temporarily moving any 32-bit libdirs out of the way. It's a long shot, |
94 |
but I can't see any harm in it as long as you aren't running anything |
95 |
32-bit when you move it, and if it has chance at working... |
96 |
|
97 |
> Building by hand works. |
98 |
|
99 |
>> configure and make manually but without the ebuild switches. Also note |
100 |
>> the "elibtoolize" at the end of the unpack step. Perhaps that's the |
101 |
>> issue. |
102 |
>> |
103 |
> Doing it in stages with ebuild fails during compile at the same place. |
104 |
> However, I can do ebuild unpack, and then run configure the same way as |
105 |
> ebuild does, and then run make by hand and it also works. |
106 |
|
107 |
Well, that eliminates the elibtoolize at the end of the unpack as the |
108 |
culprit. |
109 |
|
110 |
> I suppose it'd be good to get everything compiled/broken with gcc 4.1.1, |
111 |
> so I'm just going to give up and start an emerge -ep world tonight and |
112 |
> see what happens... |
113 |
|
114 |
One bonus you will likely see, particularly with glibc, kde if you have it |
115 |
merged, and all the parts of modular-X, is that the gcc-4.1.1 |
116 |
compiled versions should be noticeably faster than 3.4.x versions were. |
117 |
=8^) gcc 4.1 is the first gcc to be truly optimized for amd64 -- |
118 |
previous to 4.0 amd64 support was really just bolted onto the side as an |
119 |
afterthought and 4.0 was just the rewrite attempting not to have any big |
120 |
regressions, so 4.1 is the first truly optimized 4.x series so the first |
121 |
to really shine in terms of amd64 optimizations. Of course, CFLAGS and |
122 |
what you have merged as well as your specific hardware will play very big |
123 |
parts in all that as well, but I DEFINITELY noticed the difference here, |
124 |
and was duly impressed! =8^) |
125 |
|
126 |
So... even if the --emptytree doesn't solve this particular gmp issue, it |
127 |
won't be all for naught, as with any luck, you'll definitely notice the |
128 |
speed improvement! |
129 |
|
130 |
--- |
131 |
|
132 |
As for troubleshooting beyond the previous suggestions... |
133 |
|
134 |
Try a diff between the config.log (or is it configure.log, IDR) produced by |
135 |
your by-hand compile (that succeeds, and the one produced by the failing |
136 |
ebuild. I don't know why I didn't think of this earlier, but by rights |
137 |
that /ought/ to spotlight the problem! |
138 |
|
139 |
Of course, while that will likely spotlight the problem, you (or someone |
140 |
on the bug) still have to figure out what's triggering the different |
141 |
behavior. Again, all I can figure is something in the environment that |
142 |
differs between you doing it manually and portage's run, but what? Maybe |
143 |
the bug will end up being one in portage! |
144 |
|
145 |
(I think I'll cc myself to the bug, as stuff like this intrigues me, and |
146 |
I'd love to know what the problem ultimately turns out to be!) |
147 |
|
148 |
-- |
149 |
Duncan - List replies preferred. No HTML msgs. |
150 |
"Every nonfree program has a lord, a master -- |
151 |
and if you use the program, he is your master." Richard Stallman |
152 |
|
153 |
-- |
154 |
gentoo-amd64@g.o mailing list |