Gentoo Archives: gentoo-amd64

From: Duncan <1i5t5.duncan@×××.net>
To: gentoo-amd64@l.g.o
Subject: [gentoo-amd64] Re: Re: problems with gmp and portage
Date: Thu, 06 Jul 2006 14:13:05
Message-Id: e8j5iu$64k$
In Reply to: Re: [gentoo-amd64] Re: problems with gmp and portage by Kyle Liddell
1 Kyle Liddell <kyle@××××××××××××××××.net> posted
2 20060706042949.GA24867@××××××.localdomain, excerpted below, on Wed, 05
3 Jul 2006 23:29:49 -0500:
5 > On Wed, Jul 05, 2006 at 05:04:00PM +0000, Duncan wrote:
6 >> Have you run recently? I'm asking because I see
7 >> the
8 >>
9 > I always forget to run that, but I did, and still no gmp.
11 I didn't really expect it to, as those errors are usually rather
12 different, but thought it was worth a shot.
14 >> Do you routinely run your emerge --update with the --deep (-D) switch?
15 > Always.
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.
23 So anyway, that's eliminated too...
25 >> How much of your system has been recompiled with gcc-4.1.x?
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.
35 The gcc upgrade guide (
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.
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.
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.
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.
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.
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.
80 Oh yeah, I was going to mention that but forgot. You're ahead of me on
81 that! =8^)
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.
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...
97 > Building by hand works.
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.
107 Well, that eliminates the elibtoolize at the end of the unpack as the
108 culprit.
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...
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^)
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!
130 ---
132 As for troubleshooting beyond the previous suggestions...
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!
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!
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!)
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
153 --
154 gentoo-amd64@g.o mailing list