1 |
On Wed, Jul 05, 2006 at 05:04:00PM +0000, Duncan wrote: |
2 |
> Have you run fix_libtool_files.sh recently? I'm asking because I see the |
3 |
> |
4 |
I always forget to run that, but I did, and still no gmp. |
5 |
|
6 |
> Also, revdep-rebuild. Have you run it recently? (Run it with -p first, |
7 |
Yep. No help. |
8 |
|
9 |
> of course.) What about emerge --depclean (again, with -p first)? |
10 |
Nothing looked like it was related in any way. |
11 |
|
12 |
> Do you routinely run your emerge --update with the --deep (-D) switch? |
13 |
Always. |
14 |
|
15 |
> How much of your system has been recompiled with gcc-4.1.x? |
16 |
Umm...not much. If I could ever get gmp compiled, then I could get around to compiling a good chunk of the rest... |
17 |
|
18 |
However, I have built/rebuilt/rebuilt again gcc, glibc, and binutils with gcc 4.1.1. |
19 |
|
20 |
> of my system that's still compiled with gcc-3.4.x. If you haven't done an |
21 |
> emerge --emptytree world since gcc-4.1.1 was unmasked and weren't running |
22 |
> the masked 4.x versions as I was, perhaps that's the difference between it |
23 |
> working fine here and not there? |
24 |
> |
25 |
|
26 |
Ick, that's (almost) the same as a reinstall...but I think I will end up doing that. |
27 |
|
28 |
> Another possible difference... I run very little 32-bit at all, and in |
29 |
> fact have considered switching to the no-multilib profiles. (About the |
30 |
... |
31 |
> out of the way to somewhere the compile can't find them, and see if the |
32 |
> problem "magically" disappears. It's worth a shot, anyway. |
33 |
|
34 |
And oh yeah, I tried emerge'ing with -sandbox. Same deal. |
35 |
|
36 |
About all I have 32bit-wise is enough to get a flash plugin for firefox-bin. I have thought that multilib was a bit messy though, and I might try dumping it since most of my 32bit stuff only works in a chroot'd system (ISE, wine, etc). But as for this exact problem, I don't really see anything that is safe to delete/move/hide that is definitely 32bit only that could be making problems. |
37 |
|
38 |
> The system cleanliness thing is a good thing to check anyway, even if it |
39 |
> doesn't fix this particular issue, so that's good to try first. The |
40 |
... |
41 |
> configure input, that could be the culprit. In fact, I've seen it happen |
42 |
> more than once in my own troubleshooting, so be sure and check that. |
43 |
> |
44 |
Building by hand works. |
45 |
|
46 |
> Are you familiar with the ebuild command? If not, man ebuild and bone up |
47 |
> on the various stages (fetch/unpack/compile/install/qmerge, in that order) |
48 |
... |
49 |
> configure and make manually but without the ebuild switches. Also note |
50 |
> the "elibtoolize" at the end of the unpack step. Perhaps that's the issue. |
51 |
> |
52 |
Doing it in stages with ebuild fails during compile at the same place. However, I can do ebuild unpack, and then run configure the same way as ebuild does, and then run make by hand and it also works. |
53 |
|
54 |
I suppose it'd be good to get everything compiled/broken with gcc 4.1.1, so I'm just going to give up and start an emerge -ep world tonight and see what happens... |
55 |
|
56 |
Thanks for the help though. |
57 |
|
58 |
Kyle |
59 |
|
60 |
-- |
61 |
gentoo-amd64@g.o mailing list |