1 |
Kyle Liddell <kyle@××××××××××××××××.net> posted |
2 |
20060705133740.GA2652@××××××.localdomain, excerpted below, on Wed, 05 Jul |
3 |
2006 08:37:40 -0500: |
4 |
|
5 |
> (Disclaimer: This is pretty much a copy of a bug report |
6 |
> (http://bugs.gentoo.org/show_bug.cgi?id=138231), but I'm hoping somebody |
7 |
> here might have any ideas on what to try.) |
8 |
> |
9 |
> I've been unable to use emerge to update gmp from 4.2 to 4.2.1 for a |
10 |
> couple weeks now. The compile will go on for a while, and then fail with |
11 |
> "recompile with -fPIC". However, I can build gmp by hand with no |
12 |
> problems. I can apply all the patches that portage throws on, and it |
13 |
> still works. |
14 |
> |
15 |
> Does anyone have any ideas? |
16 |
|
17 |
Interesting. Take a look at the kdm (hijacked) thread too. It's the same |
18 |
-fPIC R_X86_64_32 type error there, but a bit different, and as no bug had |
19 |
been filed, all the system details from emerge --info are missing. |
20 |
|
21 |
In both cases (kdm and gmp), no issues at all merging them here. Same |
22 |
~amd64 keyworded system, altho I /was/ running the masked 4.0 and 4.1 for |
23 |
some time before 4.1.1 was released and unmasked to ~. |
24 |
|
25 |
My first thought was a corrupted ccache or confcache that kept getting |
26 |
used thru portage, and I was going to suggest disabling that, but I see |
27 |
from the bug neither of you have confcache merged and while one of you had |
28 |
ccache, it was disabled, so that can't be the issue. |
29 |
|
30 |
Have you run fix_libtool_files.sh recently? I'm asking because I see the |
31 |
*.la in the trace and both kdm and gmp appear to be C++. If some of those |
32 |
are still pointing at your old gcc-3.4.x install and not the new |
33 |
gcc-4.1.1 it could create issues, tho I can't say it would create /this/ |
34 |
one. |
35 |
|
36 |
Also, revdep-rebuild. Have you run it recently? (Run it with -p first, |
37 |
of course.) What about emerge --depclean (again, with -p first)? |
38 |
|
39 |
Do you routinely run your emerge --update with the --deep (-D) switch? |
40 |
|
41 |
How much of your system has been recompiled with gcc-4.1.x? |
42 |
|
43 |
Of course, all of these questions boil down to one thing, how good your |
44 |
general system hygiene and cleanliness is. I can't say for sure that it'll |
45 |
help, but certainly, having a bunch of old cruft hanging around gathering |
46 |
bitrot will complicate things a bit. In particular, it's possible |
47 |
something compiled with the old gcc isn't quite compatible with the new |
48 |
gcc. As I was running the masked 4.0.x and 4.1.0 for some time, and I did |
49 |
an emerge --emptytree world somewhere in the process, there's very little |
50 |
of my system that's still compiled with gcc-3.4.x. If you haven't done an |
51 |
emerge --emptytree world since gcc-4.1.1 was unmasked and weren't running |
52 |
the masked 4.x versions as I was, perhaps that's the difference between it |
53 |
working fine here and not there? |
54 |
|
55 |
Another possible difference... I run very little 32-bit at all, and in |
56 |
fact have considered switching to the no-multilib profiles. (About the |
57 |
only thing besides the 32-bit toolchain, sandbox/gcc/glibc/binutils, that |
58 |
I need multilib for, is grub, and I /could/ merge the grub-static binary |
59 |
if I were to decide to go no-multilib.) I have a rather intense aversion |
60 |
to slaveryware, so don't need 32-bit for that, and don't need OOo, so |
61 |
don't need it for that or any other "obscure" freedomware stuff that's |
62 |
still 32-bit only, so other than grub and the multilib toolchain, I'm 100% |
63 |
64-bit. The R_x86_64_32 name hints that it /might/ be 32-bit related. Do |
64 |
both you guys have lots of 32-bit stuff installed or are you like me, |
65 |
nearly all 64-bit? Maybe it's another problem like the opengl problem, |
66 |
with the compile unsuccessfully of course trying to use the 32-bit libs |
67 |
for some reason. Since I have very few of them on my system, I wouldn't |
68 |
have that problem, just as I don't have that particular opengl problem. |
69 |
If you have a lot of 32-bit libraries, try temporarily moving those dirs |
70 |
out of the way to somewhere the compile can't find them, and see if the |
71 |
problem "magically" disappears. It's worth a shot, anyway. |
72 |
|
73 |
The system cleanliness thing is a good thing to check anyway, even if it |
74 |
doesn't fix this particular issue, so that's good to try first. The |
75 |
32-bit thing is simple enough to try, so that's next. Beyond that, given |
76 |
that it compiles fine outside portage, the issue must be one of the |
77 |
differing environment between the portage compile and doing it on your |
78 |
own. |
79 |
|
80 |
Since you've checked the patches, you've probably checked this too, but you |
81 |
didn't mention it so I will. Did you try exactly duplicating the ebuild's |
82 |
configure (econf) switches? If you are aren't giving it the same |
83 |
configure input, that could be the culprit. In fact, I've seen it happen |
84 |
more than once in my own troubleshooting, so be sure and check that. |
85 |
|
86 |
Are you familiar with the ebuild command? If not, man ebuild and bone up |
87 |
on the various stages (fetch/unpack/compile/install/qmerge, in that order) |
88 |
that emerge automates, then try doing them by hand. In particular, |
89 |
compare ebuild compile, with ebuild unpack, then doing the configure |
90 |
(using the ebuild switches) and make manually, with unpack and doing the |
91 |
configure and make manually but without the ebuild switches. Also note |
92 |
the "elibtoolize" at the end of the unpack step. Perhaps that's the issue. |
93 |
|
94 |
Kind of shots in the dark -- unfortunately I don't understand the issues |
95 |
well enough to do better than that -- but maybe they'll be of help... |
96 |
|
97 |
-- |
98 |
Duncan - List replies preferred. No HTML msgs. |
99 |
"Every nonfree program has a lord, a master -- |
100 |
and if you use the program, he is your master." Richard Stallman |
101 |
|
102 |
-- |
103 |
gentoo-amd64@g.o mailing list |