1 |
On 21 August 2010 18:37, Brent Busby <brent@×××××××××.org> wrote: |
2 |
> On Sat, 21 Aug 2010, Duncan wrote: |
3 |
> |
4 |
>> Brent Busby posted on Fri, 20 Aug 2010 13:37:15 -0500 as excerpted: |
5 |
>> |
6 |
>>> As an addendum to the above, I found this thread: |
7 |
>>> |
8 |
>>> http://forums.gentoo.org/viewtopic-t-831467.html? |
9 |
>> |
10 |
>> sid=8182796e790caf6a0c9dd589570c8a4f |
11 |
>>> |
12 |
>>> It looks like the build for akode is trying to find libakode.so before |
13 |
>>> it's actually been finished compiling. I still don't know what to do |
14 |
>>> about that, or why it would be happening now under GCC 4.4 when it |
15 |
>>> wasn't before, unless it's a libtool "--as-needed" related thing. |
16 |
>> |
17 |
>> IIRC, I had decided I didn't actually need akode for my usage long before |
18 |
>> I ever switched to kde4, and thus haven't compiled it in... years, now. I |
19 |
>> believe I was running into issues that lead to that investigation and |
20 |
>> conclusion, that may be similar to what you're running into now. (FWIW, I |
21 |
>> run ~arch and often unmask and run the latest gcc well before it's even |
22 |
>> unmasked to ~arch, and am running gcc-4.5.1 now, so I'd have seen gcc-4.4 |
23 |
>> issues quite some time ago, tho I think this was long before that, |
24 |
>> possibly as far back as the gcc-3.5 era.) |
25 |
>> |
26 |
>> But, you mention a "new machine", presumably a multi-core machine, that |
27 |
>> you're taking advantage of with MAKEOPTS=-jX, with X>1. While your |
28 |
>> previous machines may also be multi-core, for various reasons they may |
29 |
>> have used a different make job scheduling order and thus not run into the |
30 |
>> problem. Or, perhaps it's a combination of that and --as-needed. |
31 |
> |
32 |
> Actually, the new machine plus the two previous machines have all had SMP. |
33 |
> But I've never used a -j option on any of them, because the fact that |
34 |
> parallel compilation doesn't always work right has always scared me away |
35 |
> from it and made me worry I could be causing myself unnecessary grief in the |
36 |
> future with hard-to-diagnose issues. I'd love to use it to get builds done |
37 |
> faster, but the extra speed has never been worth it to me if I can't |
38 |
> entirely trust it. |
39 |
> |
40 |
> So, I've never used any '-j' setting in MAKEOPTS on any system. Is it |
41 |
> possible that with GCC 4.4 I'm getting some kind of implied parallel |
42 |
> execution anyway though, requiring me to set '-j1' to override it for this |
43 |
> package? |
44 |
> |
45 |
>> I've also been |
46 |
>> running --as-needed in my LDFLAGS, since 2006 or 2007 I'd guess, so it's |
47 |
>> indeed quite conceivable that I'd have run into parallel make issues, |
48 |
>> perhaps related to --as-needed, perhaps not, way back when I /was/ still |
49 |
>> building akode, if the package is wont to trigger them, as it seems to be. |
50 |
> |
51 |
> This is the first machine I've installed from scratch since '--as-needed' |
52 |
> became part of the desktop policy. It's never seen a libtool environment |
53 |
> that doesn't use it -- I don't know if that has anything to do with this |
54 |
> problem or not though. |
55 |
> |
56 |
>> So... try building the package with MAKEOPTS=-j1 and see if that works. |
57 |
>> If so, it's a workaround; the makefile dependencies should really be fixed |
58 |
>> properly, but that takes some make file (and possibly other) knowledge few |
59 |
>> folks have, apparently even at the Gentoo developer level. A lot of the |
60 |
>> time, therefore, such issues are simply worked around, with the ebuild |
61 |
>> hard-coding MAKEOPTS=-j1. So assuming it works, that's likely the change |
62 |
>> that'll happen -- make the ebuild hardcode MAKEOPTS=-j1. |
63 |
> |
64 |
> Just tried it, unfortunately, it did the same thing: |
65 |
> |
66 |
> Making all in src_resampler |
67 |
> make[4]: Entering directory |
68 |
> `/var/tmp/portage/media-libs/akode-2.0.2/work/akode-2.0.2/akode/plugins/src_resampler' |
69 |
> if /bin/sh ../../../libtool --silent --tag=CXX --mode=compile |
70 |
> x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I. -I../../.. |
71 |
> -I../../../akode/lib -I../../../akode/lib -I../../../akode/lib -I./mppdec |
72 |
> -O2 -march=athlon64 -pipe -MT src_resampler.lo -MD -MP -MF |
73 |
> ".deps/src_resampler.Tpo" -c -o src_resampler.lo src_resampler.cpp; \ |
74 |
> then mv -f ".deps/src_resampler.Tpo" ".deps/src_resampler.Plo"; else |
75 |
> rm -f ".deps/src_resampler.Tpo"; exit 1; fi |
76 |
> /bin/sh ../../../libtool --silent --tag=CXX --mode=link |
77 |
> x86_64-pc-linux-gnu-g++ -O2 -march=athlon64 -pipe -Wl,-O1 -Wl,--as-needed |
78 |
> -o libakode_src_resampler.la -rpath /usr/lib64 -module -avoid-version |
79 |
> -no-undefined -Wl,--no-undefined -Wl,--allow-shlib-undefined |
80 |
> src_resampler.lo ../../lib/libakode.la -lsamplerate |
81 |
> make[4]: Leaving directory |
82 |
> `/var/tmp/portage/media-libs/akode-2.0.2/work/akode-2.0.2/akode/plugins/src_resampler' |
83 |
> make[4]: Entering directory |
84 |
> `/var/tmp/portage/media-libs/akode-2.0.2/work/akode-2.0.2/akode/plugins' |
85 |
> make[4]: Nothing to be done for `all-am'. |
86 |
> make[4]: Leaving directory |
87 |
> `/var/tmp/portage/media-libs/akode-2.0.2/work/akode-2.0.2/akode/plugins' |
88 |
> make[3]: Leaving directory |
89 |
> `/var/tmp/portage/media-libs/akode-2.0.2/work/akode-2.0.2/akode/plugins' |
90 |
> Making all in akodeplay |
91 |
> make[3]: Entering directory |
92 |
> `/var/tmp/portage/media-libs/akode-2.0.2/work/akode-2.0.2/akode/akodeplay' |
93 |
> if x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I../../akode/lib |
94 |
> -I../../akode/lib -I../../akode/lib -O2 -march=athlon64 -pipe -MT |
95 |
> akodeplay.o -MD -MP -MF ".deps/akodeplay.Tpo" -c -o akodeplay.o |
96 |
> akodeplay.cpp; \ |
97 |
> then mv -f ".deps/akodeplay.Tpo" ".deps/akodeplay.Po"; else rm -f |
98 |
> ".deps/akodeplay.Tpo"; exit 1; fi |
99 |
> /bin/sh ../../libtool --silent --tag=CXX --mode=link x86_64-pc-linux-gnu-g++ |
100 |
> -O2 -march=athlon64 -pipe -Wl,-O1 -Wl,--as-needed -o akodeplay |
101 |
> akodeplay.o ../lib/libakode.la |
102 |
> x86_64-pc-linux-gnu-g++: ../lib/.libs/libakode.so: No such file or directory |
103 |
> make[3]: *** [akodeplay] Error 1 |
104 |
> |
105 |
>> (FWIW, I'm not going to discount the reasons many still run kde3, as until |
106 |
>> 4.4 and better, 4.5, despite official kde announcements to the contrary, |
107 |
>> kde4 was simply too bug riddled to be reasonably usable, and I spent well |
108 |
>> over 100 hours finding workaround, often scripting my own, and otherwise |
109 |
>> making an otherwise broken kde-4.2.4 work for me when I switched so I KNOW |
110 |
>> this to be true, but one thing I *DO* appreciate about kde4 is how much more |
111 |
>> effectively it parallel builds in comparison to kde3, therefore taking about |
112 |
>> half the build time on a 4-core including my dual-dual-core system, compared |
113 |
>> to kde3. It's NICE to be able to do a kde4 upgrade in the 4 hours or so it |
114 |
>> takes now, depending on how much is new code and how much is not in ccache, |
115 |
>> compared to the entire day, 6-8 hours, if there weren't other problems, it'd |
116 |
>> take to do the same with kde3.) |
117 |
> |
118 |
> Yeah, but the problem with it to me is it just isn't the same desktop |
119 |
> anymore. Most of it seems to be imitating Windows Vista/7, with a few |
120 |
> things derived from MacOS/X here and there (like the new Control Panel, |
121 |
> which strongly resembles the Mac's System Preferences app). KDE 3 used to |
122 |
> let you make desktops that were totally different. |
123 |
> |
124 |
> My own desktop actually resembles -- and this will probably puzzle some |
125 |
> people -- CDE from HP-UX. I'm one of those strange people who actually like |
126 |
> an X11 desktop to look like an X11 desktop. I find that most "modern" |
127 |
> desktops from Microsoft look and feel like a credit card advertisement, |
128 |
> while most modern desktops from Apple look like a 70's car stereo (brushed |
129 |
> chrome everywhere!). It seems to be very out of fashion now to prefer one's |
130 |
> computer look and act like...gasp!...a computer, but that's what I like, and |
131 |
> up until KDE 4, KDE was providing a very nice CDE emulation. (Actually, KDE |
132 |
> 3's imitation of CDE is quite a bit more functional that real CDE...no shock |
133 |
> there, I suppose.) |
134 |
> |
135 |
> Plus there's the fact that KDE 4, even now that it's more stable, seems to |
136 |
> use resources like we had them to burn. Actually, on modern machines, that |
137 |
> might be true, but I run studio recording apps, which is a genre of |
138 |
> application where more bandwidth equals more tracks, more plugins, more disk |
139 |
> i/o, etc. It's one of the few remaining types of apps these days that are |
140 |
> *not* just leaving your system idle most of the time, and really do want all |
141 |
> you can give them. People who are running pro audio apps do not have |
142 |
> CPU/RAM to burn, ever, even on a fast machine! If you are running such |
143 |
> programs, and your machine has more to give, you want to give it to the |
144 |
> apps, not the desktop, no matter how *much* more that is. |
145 |
> |
146 |
> So in general, KDE 4 has turned me away. I'll pass on its Windows Vista |
147 |
> look and feel, its enormous resource footprint, and the way they made |
148 |
> keeping any semblance of my current CDE-ish KDE desktop unsupportable. |
149 |
> |
150 |
>> So for testing and to work around the issue yourself until it's fixed in |
151 |
>> the ebuild, use the env file. Once either a proper fix or at least the |
152 |
>> MAKEOPTS=j1 workaround (assuming it fixes the problem) is in the ebuild, you |
153 |
>> can remove the env file workaround. No more having to change global |
154 |
>> make.conf settings for a single package, then having to change them back! |
155 |
>> =:^) |
156 |
> |
157 |
> Thanks for the help, but that didn't seem to fix it. I never use '-j' |
158 |
> options anyway. I'll probably start if they ever start working all the |
159 |
> time. |
160 |
> |
161 |
> -- |
162 |
> + Brent A. Busby + "We've all heard that a million monkeys |
163 |
> + UNIX Systems Admin + banging on a million typewriters will |
164 |
> + University of Chicago + eventually reproduce the entire works of |
165 |
> + Physical Sciences Div. + Shakespeare. Now, thanks to the Internet, |
166 |
> + James Franck Institute + we know this is not true." -Robert Wilensky |
167 |
> |
168 |
> |
169 |
|
170 |
Can you post the full build log as an attachment or URL? All I can |
171 |
tell from the current output is that libakode.la is not being produced |
172 |
by something earlier in the build. |
173 |
|
174 |
If this is an as-needed issue, the problem is likely to be that akode |
175 |
was implicitly relying on a dependent library bringing in another |
176 |
library it needs and it no longer does that because of as-needed. |
177 |
I've already seen patches going into the mainline packages to fix such |
178 |
issues (may be worth checking if you have any pending updates). I hit |
179 |
at least one issue like this when rebuilding after the --as-needed |
180 |
change went in. |
181 |
|
182 |
Adding stuff like --as-needed may help the occasional libpng upgrade, |
183 |
but it means packages may be being built in a way that isn't being |
184 |
tested regularly by its developers. |
185 |
-- |
186 |
Andrew :-) |
187 |
|
188 |
Free Java Software Engineer |
189 |
Red Hat, Inc. (http://www.redhat.com) |
190 |
|
191 |
Support Free Java! |
192 |
Contribute to GNU Classpath and the OpenJDK |
193 |
http://www.gnu.org/software/classpath |
194 |
http://openjdk.java.net |
195 |
|
196 |
PGP Key: 94EFD9D8 (http://subkeys.pgp.net) |
197 |
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 |