On 21 August 2010 18:37, Brent Busby <[email protected]> wrote: > On Sat, 21 Aug 2010, Duncan wrote: > >> Brent Busby posted on Fri, 20 Aug 2010 13:37:15 -0500 as excerpted: >> >>> As an addendum to the above, I found this thread: >>> >>> http://forums.gentoo.org/viewtopic-t-831467.html? >> >> sid=8182796e790caf6a0c9dd589570c8a4f >>> >>> It looks like the build for akode is trying to find libakode.so before >>> it's actually been finished compiling. I still don't know what to do >>> about that, or why it would be happening now under GCC 4.4 when it >>> wasn't before, unless it's a libtool "--as-needed" related thing. >> >> IIRC, I had decided I didn't actually need akode for my usage long before >> I ever switched to kde4, and thus haven't compiled it in... years, now. I >> believe I was running into issues that lead to that investigation and >> conclusion, that may be similar to what you're running into now. (FWIW, I >> run ~arch and often unmask and run the latest gcc well before it's even >> unmasked to ~arch, and am running gcc-4.5.1 now, so I'd have seen gcc-4.4 >> issues quite some time ago, tho I think this was long before that, >> possibly as far back as the gcc-3.5 era.) >> >> But, you mention a "new machine", presumably a multi-core machine, that >> you're taking advantage of with MAKEOPTS=-jX, with X>1. While your >> previous machines may also be multi-core, for various reasons they may >> have used a different make job scheduling order and thus not run into the >> problem. Or, perhaps it's a combination of that and --as-needed. > > Actually, the new machine plus the two previous machines have all had SMP. > But I've never used a -j option on any of them, because the fact that > parallel compilation doesn't always work right has always scared me away > from it and made me worry I could be causing myself unnecessary grief in the > future with hard-to-diagnose issues. I'd love to use it to get builds done > faster, but the extra speed has never been worth it to me if I can't > entirely trust it. > > So, I've never used any '-j' setting in MAKEOPTS on any system. Is it > possible that with GCC 4.4 I'm getting some kind of implied parallel > execution anyway though, requiring me to set '-j1' to override it for this > package? > >> I've also been >> running --as-needed in my LDFLAGS, since 2006 or 2007 I'd guess, so it's >> indeed quite conceivable that I'd have run into parallel make issues, >> perhaps related to --as-needed, perhaps not, way back when I /was/ still >> building akode, if the package is wont to trigger them, as it seems to be. > > This is the first machine I've installed from scratch since '--as-needed' > became part of the desktop policy. It's never seen a libtool environment > that doesn't use it -- I don't know if that has anything to do with this > problem or not though. > >> So... try building the package with MAKEOPTS=-j1 and see if that works. >> If so, it's a workaround; the makefile dependencies should really be fixed >> properly, but that takes some make file (and possibly other) knowledge few >> folks have, apparently even at the Gentoo developer level. A lot of the >> time, therefore, such issues are simply worked around, with the ebuild >> hard-coding MAKEOPTS=-j1. So assuming it works, that's likely the change >> that'll happen -- make the ebuild hardcode MAKEOPTS=-j1. > > Just tried it, unfortunately, it did the same thing: > > Making all in src_resampler > make[4]: Entering directory > `/var/tmp/portage/media-libs/akode-2.0.2/work/akode-2.0.2/akode/plugins/src_resampler' > if /bin/sh ../../../libtool --silent --tag=CXX --mode=compile > x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I. -I../../.. > -I../../../akode/lib -I../../../akode/lib -I../../../akode/lib -I./mppdec > -O2 -march=athlon64 -pipe -MT src_resampler.lo -MD -MP -MF > ".deps/src_resampler.Tpo" -c -o src_resampler.lo src_resampler.cpp; \ > then mv -f ".deps/src_resampler.Tpo" ".deps/src_resampler.Plo"; else > rm -f ".deps/src_resampler.Tpo"; exit 1; fi > /bin/sh ../../../libtool --silent --tag=CXX --mode=link > x86_64-pc-linux-gnu-g++ -O2 -march=athlon64 -pipe -Wl,-O1 -Wl,--as-needed > -o libakode_src_resampler.la -rpath /usr/lib64 -module -avoid-version > -no-undefined -Wl,--no-undefined -Wl,--allow-shlib-undefined > src_resampler.lo ../../lib/libakode.la -lsamplerate > make[4]: Leaving directory > `/var/tmp/portage/media-libs/akode-2.0.2/work/akode-2.0.2/akode/plugins/src_resampler' > make[4]: Entering directory > `/var/tmp/portage/media-libs/akode-2.0.2/work/akode-2.0.2/akode/plugins' > make[4]: Nothing to be done for `all-am'. > make[4]: Leaving directory > `/var/tmp/portage/media-libs/akode-2.0.2/work/akode-2.0.2/akode/plugins' > make[3]: Leaving directory > `/var/tmp/portage/media-libs/akode-2.0.2/work/akode-2.0.2/akode/plugins' > Making all in akodeplay > make[3]: Entering directory > `/var/tmp/portage/media-libs/akode-2.0.2/work/akode-2.0.2/akode/akodeplay' > if x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I../../akode/lib > -I../../akode/lib -I../../akode/lib -O2 -march=athlon64 -pipe -MT > akodeplay.o -MD -MP -MF ".deps/akodeplay.Tpo" -c -o akodeplay.o > akodeplay.cpp; \ > then mv -f ".deps/akodeplay.Tpo" ".deps/akodeplay.Po"; else rm -f > ".deps/akodeplay.Tpo"; exit 1; fi > /bin/sh ../../libtool --silent --tag=CXX --mode=link x86_64-pc-linux-gnu-g++ > -O2 -march=athlon64 -pipe -Wl,-O1 -Wl,--as-needed -o akodeplay > akodeplay.o ../lib/libakode.la > x86_64-pc-linux-gnu-g++: ../lib/.libs/libakode.so: No such file or directory > make[3]: *** [akodeplay] Error 1 > >> (FWIW, I'm not going to discount the reasons many still run kde3, as until >> 4.4 and better, 4.5, despite official kde announcements to the contrary, >> kde4 was simply too bug riddled to be reasonably usable, and I spent well >> over 100 hours finding workaround, often scripting my own, and otherwise >> making an otherwise broken kde-4.2.4 work for me when I switched so I KNOW >> this to be true, but one thing I *DO* appreciate about kde4 is how much more >> effectively it parallel builds in comparison to kde3, therefore taking about >> half the build time on a 4-core including my dual-dual-core system, compared >> to kde3. It's NICE to be able to do a kde4 upgrade in the 4 hours or so it >> takes now, depending on how much is new code and how much is not in ccache, >> compared to the entire day, 6-8 hours, if there weren't other problems, it'd >> take to do the same with kde3.) > > Yeah, but the problem with it to me is it just isn't the same desktop > anymore. Most of it seems to be imitating Windows Vista/7, with a few > things derived from MacOS/X here and there (like the new Control Panel, > which strongly resembles the Mac's System Preferences app). KDE 3 used to > let you make desktops that were totally different. > > My own desktop actually resembles -- and this will probably puzzle some > people -- CDE from HP-UX. I'm one of those strange people who actually like > an X11 desktop to look like an X11 desktop. I find that most "modern" > desktops from Microsoft look and feel like a credit card advertisement, > while most modern desktops from Apple look like a 70's car stereo (brushed > chrome everywhere!). It seems to be very out of fashion now to prefer one's > computer look and act like...gasp!...a computer, but that's what I like, and > up until KDE 4, KDE was providing a very nice CDE emulation. (Actually, KDE > 3's imitation of CDE is quite a bit more functional that real CDE...no shock > there, I suppose.) > > Plus there's the fact that KDE 4, even now that it's more stable, seems to > use resources like we had them to burn. Actually, on modern machines, that > might be true, but I run studio recording apps, which is a genre of > application where more bandwidth equals more tracks, more plugins, more disk > i/o, etc. It's one of the few remaining types of apps these days that are > *not* just leaving your system idle most of the time, and really do want all > you can give them. People who are running pro audio apps do not have > CPU/RAM to burn, ever, even on a fast machine! If you are running such > programs, and your machine has more to give, you want to give it to the > apps, not the desktop, no matter how *much* more that is. > > So in general, KDE 4 has turned me away. I'll pass on its Windows Vista > look and feel, its enormous resource footprint, and the way they made > keeping any semblance of my current CDE-ish KDE desktop unsupportable. > >> So for testing and to work around the issue yourself until it's fixed in >> the ebuild, use the env file. Once either a proper fix or at least the >> MAKEOPTS=j1 workaround (assuming it fixes the problem) is in the ebuild, you >> can remove the env file workaround. No more having to change global >> make.conf settings for a single package, then having to change them back! >> =:^) > > Thanks for the help, but that didn't seem to fix it. I never use '-j' > options anyway. I'll probably start if they ever start working all the > time. > > -- > + Brent A. Busby + "We've all heard that a million monkeys > + UNIX Systems Admin + banging on a million typewriters will > + University of Chicago + eventually reproduce the entire works of > + Physical Sciences Div. + Shakespeare. Now, thanks to the Internet, > + James Franck Institute + we know this is not true." -Robert Wilensky > >
Can you post the full build log as an attachment or URL? All I can tell from the current output is that libakode.la is not being produced by something earlier in the build. If this is an as-needed issue, the problem is likely to be that akode was implicitly relying on a dependent library bringing in another library it needs and it no longer does that because of as-needed. I've already seen patches going into the mainline packages to fix such issues (may be worth checking if you have any pending updates). I hit at least one issue like this when rebuilding after the --as-needed change went in. Adding stuff like --as-needed may help the occasional libpng upgrade, but it means packages may be being built in a way that isn't being tested regularly by its developers. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
