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.
FWIW... my main machine is a dual socket Opteron 2xx, now top-of-its-line
Opteron 290s, so dual-dual-cores, but for years I ran dual Opteron 242s,
single-core, but two of them, so I've been running into parallel make
errors since I switched to Gentoo on the system in 2004. 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.
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.
(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.)
Meanwhile, until it gets into the ebuild, assuming you're using portage
(the other two package managers have their own system for this), you can
set the MAKEOPTS=-j1 for that specific package only, using /etc/portage/
env. This trick isn't well known or documented for what are now mostly
historical reasons (devs objected to making it too public as package
specific settings weren't reported in emerge --info, thus making
troubleshooting bugs difficult, but emerge --info <package> now reports
where settings for that package differ from the global settings), but
here's how to do it:
1) If the directory doesn't already exist, create /etc/portage/env/ with
the same ownership and permissions as /etc/portage/ .
2) The structure under env/ is category subdirs, package files. Thus, for
this package, you'll have the file /etc/portage/env/media-libs/akode .
Again, permissions should be similar to those in /etc/portage.
3) In /etc/portage/env/media-libs/akode , place the following line:
MAKEOPTS=-j1
That should be all there is to it. Portage should now always use only a
single job when building akode. I routinely use /etc/portage/env files
for setting single MAKEOPTS jobs and it works well. =:^)
/etc/portage/env/*/* files can be used for package specific cflags, etc,
too. In fact, they should work for anything that affects only the bash
side of portage, and because they /are/ bash, bash tricks like the
following also work:
I have this in /etc/portage/env/sys-fs/mdadm (one of several packages with
the issue), removing the -combine CFLAG from my normal CFLAGS using bash's
${var//} substitution construct, since mdadm doesn't like -combine.
CFLAGS="${CFLAGS/ -combine/}"
The one caveat that at least used to apply to /etc/portage/env/ files (I'm
not positive it still does as I've not had need of the missed
functionality, here) is that they're sourced into the bash side of
portage, namely, ebuild.sh, not the python side. So settings that affect
the python side (like some FEATURES) may not work as intended, while those
only affecting the bash side should. So changes affecting dependency
calculation, which is done on the python side, etc, might not "take". If
in doubt, simply try it and see.
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!
=:^)
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
