1 |
Brent Busby posted on Fri, 20 Aug 2010 13:37:15 -0500 as excerpted: |
2 |
|
3 |
> As an addendum to the above, I found this thread: |
4 |
> |
5 |
> http://forums.gentoo.org/viewtopic-t-831467.html? |
6 |
sid=8182796e790caf6a0c9dd589570c8a4f |
7 |
> |
8 |
> It looks like the build for akode is trying to find libakode.so before |
9 |
> it's actually been finished compiling. I still don't know what to do |
10 |
> about that, or why it would be happening now under GCC 4.4 when it |
11 |
> wasn't before, unless it's a libtool "--as-needed" related thing. |
12 |
|
13 |
IIRC, I had decided I didn't actually need akode for my usage long before |
14 |
I ever switched to kde4, and thus haven't compiled it in... years, now. I |
15 |
believe I was running into issues that lead to that investigation and |
16 |
conclusion, that may be similar to what you're running into now. (FWIW, I |
17 |
run ~arch and often unmask and run the latest gcc well before it's even |
18 |
unmasked to ~arch, and am running gcc-4.5.1 now, so I'd have seen gcc-4.4 |
19 |
issues quite some time ago, tho I think this was long before that, |
20 |
possibly as far back as the gcc-3.5 era.) |
21 |
|
22 |
But, you mention a "new machine", presumably a multi-core machine, that |
23 |
you're taking advantage of with MAKEOPTS=-jX, with X>1. While your |
24 |
previous machines may also be multi-core, for various reasons they may |
25 |
have used a different make job scheduling order and thus not run into the |
26 |
problem. Or, perhaps it's a combination of that and --as-needed. |
27 |
|
28 |
FWIW... my main machine is a dual socket Opteron 2xx, now top-of-its-line |
29 |
Opteron 290s, so dual-dual-cores, but for years I ran dual Opteron 242s, |
30 |
single-core, but two of them, so I've been running into parallel make |
31 |
errors since I switched to Gentoo on the system in 2004. I've also been |
32 |
running --as-needed in my LDFLAGS, since 2006 or 2007 I'd guess, so it's |
33 |
indeed quite conceivable that I'd have run into parallel make issues, |
34 |
perhaps related to --as-needed, perhaps not, way back when I /was/ still |
35 |
building akode, if the package is wont to trigger them, as it seems to be. |
36 |
|
37 |
So... try building the package with MAKEOPTS=-j1 and see if that works. |
38 |
If so, it's a workaround; the makefile dependencies should really be fixed |
39 |
properly, but that takes some make file (and possibly other) knowledge few |
40 |
folks have, apparently even at the Gentoo developer level. A lot of the |
41 |
time, therefore, such issues are simply worked around, with the ebuild |
42 |
hard-coding MAKEOPTS=-j1. So assuming it works, that's likely the change |
43 |
that'll happen -- make the ebuild hardcode MAKEOPTS=-j1. |
44 |
|
45 |
(FWIW, I'm not going to discount the reasons many still run kde3, as until |
46 |
4.4 and better, 4.5, despite official kde announcements to the contrary, |
47 |
kde4 was simply too bug riddled to be reasonably usable, and I spent well |
48 |
over 100 hours finding workaround, often scripting my own, and otherwise |
49 |
making an otherwise broken kde-4.2.4 work for me when I switched so I KNOW |
50 |
this to be true, but one thing I *DO* appreciate about kde4 is how much |
51 |
more effectively it parallel builds in comparison to kde3, therefore |
52 |
taking about half the build time on a 4-core including my dual-dual-core |
53 |
system, compared to kde3. It's NICE to be able to do a kde4 upgrade in |
54 |
the 4 hours or so it takes now, depending on how much is new code and how |
55 |
much is not in ccache, compared to the entire day, 6-8 hours, if there |
56 |
weren't other problems, it'd take to do the same with kde3.) |
57 |
|
58 |
Meanwhile, until it gets into the ebuild, assuming you're using portage |
59 |
(the other two package managers have their own system for this), you can |
60 |
set the MAKEOPTS=-j1 for that specific package only, using /etc/portage/ |
61 |
env. This trick isn't well known or documented for what are now mostly |
62 |
historical reasons (devs objected to making it too public as package |
63 |
specific settings weren't reported in emerge --info, thus making |
64 |
troubleshooting bugs difficult, but emerge --info <package> now reports |
65 |
where settings for that package differ from the global settings), but |
66 |
here's how to do it: |
67 |
|
68 |
1) If the directory doesn't already exist, create /etc/portage/env/ with |
69 |
the same ownership and permissions as /etc/portage/ . |
70 |
|
71 |
2) The structure under env/ is category subdirs, package files. Thus, for |
72 |
this package, you'll have the file /etc/portage/env/media-libs/akode . |
73 |
Again, permissions should be similar to those in /etc/portage. |
74 |
|
75 |
3) In /etc/portage/env/media-libs/akode , place the following line: |
76 |
|
77 |
MAKEOPTS=-j1 |
78 |
|
79 |
That should be all there is to it. Portage should now always use only a |
80 |
single job when building akode. I routinely use /etc/portage/env files |
81 |
for setting single MAKEOPTS jobs and it works well. =:^) |
82 |
|
83 |
/etc/portage/env/*/* files can be used for package specific cflags, etc, |
84 |
too. In fact, they should work for anything that affects only the bash |
85 |
side of portage, and because they /are/ bash, bash tricks like the |
86 |
following also work: |
87 |
|
88 |
I have this in /etc/portage/env/sys-fs/mdadm (one of several packages with |
89 |
the issue), removing the -combine CFLAG from my normal CFLAGS using bash's |
90 |
${var//} substitution construct, since mdadm doesn't like -combine. |
91 |
|
92 |
CFLAGS="${CFLAGS/ -combine/}" |
93 |
|
94 |
|
95 |
The one caveat that at least used to apply to /etc/portage/env/ files (I'm |
96 |
not positive it still does as I've not had need of the missed |
97 |
functionality, here) is that they're sourced into the bash side of |
98 |
portage, namely, ebuild.sh, not the python side. So settings that affect |
99 |
the python side (like some FEATURES) may not work as intended, while those |
100 |
only affecting the bash side should. So changes affecting dependency |
101 |
calculation, which is done on the python side, etc, might not "take". If |
102 |
in doubt, simply try it and see. |
103 |
|
104 |
So for testing and to work around the issue yourself until it's fixed in |
105 |
the ebuild, use the env file. Once either a proper fix or at least the |
106 |
MAKEOPTS=j1 workaround (assuming it fixes the problem) is in the ebuild, |
107 |
you can remove the env file workaround. No more having to change global |
108 |
make.conf settings for a single package, then having to change them back! |
109 |
=:^) |
110 |
|
111 |
-- |
112 |
Duncan - List replies preferred. No HTML msgs. |
113 |
"Every nonfree program has a lord, a master -- |
114 |
and if you use the program, he is your master." Richard Stallman |