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
