Re: [gentoo-desktop] Re: kde-sunset: new akode build problems

[Brent Busby]

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