Re: Re: kde-sunset: new akode build problems

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