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

[Duncan]

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