Gentoo Archives: gentoo-amd64

From: Duncan <1i5t5.duncan@×××.net>
To: gentoo-amd64@l.g.o
Subject: [gentoo-amd64] Re: problems with gmp and portage
Date: Wed, 05 Jul 2006 17:12:20
Message-Id: e8gre0$vh3$
In Reply to: [gentoo-amd64] problems with gmp and portage by Kyle Liddell
1 Kyle Liddell <kyle@××××××××××××××××.net> posted
2 20060705133740.GA2652@××××××.localdomain, excerpted below, on Wed, 05 Jul
3 2006 08:37:40 -0500:
5 > (Disclaimer: This is pretty much a copy of a bug report
6 > (, 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?
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.
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 ~.
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.
30 Have you run 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.
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)?
39 Do you routinely run your emerge --update with the --deep (-D) switch?
41 How much of your system has been recompiled with gcc-4.1.x?
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?
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.
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.
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.
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.
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...
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
102 --
103 gentoo-amd64@g.o mailing list


Subject Author
Re: [gentoo-amd64] Re: problems with gmp and portage Kyle Liddell <kyle@××××××××××××××××.net>