1i5t5.duncan at cox
Aug 22, 2010, 1:23 AM
Post #8 of 31
Brent Busby posted on Sat, 21 Aug 2010 12:37:40 -0500 as excerpted:
> 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?
FWIW, the type of breakage parallel make issues cause is, AFAIK, always a
build-time breakage. If it builds fine but fails at run-time, it's not
due to parallel make, but due to some other reason.
Given that, you should be able to enable parallel make without worrying
about it. The time it saves is well worth the occasional breakage with
resulting halted merge, and then having to test and add a MAKEOPTS var to
the appropriate /etc/portage/env file. Additionally, any errors you do
run into are likely to be pretty well front-loaded. That is, you'll get
them the first time you recompile that package after you enable parallel
make, but after testing and finding that's the problem once (and hopefully
checking for and reporting a bug if there's not one already filed), you
can stick MAKEOPTS=-j1 in the appropriate env file, and won't have to
worry about it again (unless you want to test to see if it's fixed, a few
versions later), as the system will always use the env file setting for
that package from then on. So after you've rebuilt your system a time or
two, you'll seldom have the issue any more (unless upstream introduced a
new bug), as all the problem packages will have -j1 already set in their
env file, and will thus build without issue.
Certainly, that's what I've found here. But the problem is much rarer
than it was at least on mainline packages anyway (meaning I have fewer
such env files than I used to, as I filed bugs, which eventually got fixed
or at least worked around with a -j1 in the ebuild), as the ones with
problems have all long since been reported and fixed or worked around by
now. You may still find the occasional issue with a freshly introduced
bug on an upgrade (tho it's unlikely on stable since ~arch will have
likely caught it), and may find it on occasional obscure packages that
nobody's bugged yet, but most definitely, the issue's FAR less common than
it was, back before multi-cores became popular and I was one of the few
running a dual CPU system, as there's FAR more wide testing for it, these
days, and the bugs have for the most part been fixed by now.
> 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.
FWIW, I installed Gentoo/~x86 from stages on my netbook, only a few months
ago. I stuck --as-needed (plus a couple other select LDFLAGS I use) on
it before the first build, so I /have/ actually done it.
But as mentioned, I've already switched to kde4, and installed it
directly, so that machine never saw kde3. Given the overlay situation,
all of kde3 would definitely qualify as "obscure packages" that won't have
had the testing that mainline stuff, including kde4, has had. So I can't
say it'd surprise me to find that kde3 had a few packages that didn't like
>> So... try building the package with MAKEOPTS=-j1 and see if that works.
> Just tried it, unfortunately, it did the same thing:
Well, that one shot down, unfortunately!
>> (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.
Keeping in mind what I said about not discounting anyone's reasons for
still running kde3... May it continue to serve you well as long as you
continue to choose it!
I've never met a desktop environment that I liked in default config. FWIW,
that's one of the reasons I'm a kde guy, as the lack of proper config
options for gnome drives me crazy.
And kde4 is now actually even more configurable than kde3 was, including
ways to turn much of the "bling" off (and reset the desktop to the
traditional single desktop folder icon based view), making it much like
kde3. It's still some work reconfiguring stuff, but that can be expected
from any upgrade of that size, and with 4.5, in general it's now only what
one would expect to have to reconfigure with a major version bump upgrade,
with little remaining of the the 100+ hour hell of additional brokenness
workarounds, etc, that I had to do back with 4.2.4.
> 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.)
Well, I don't know /what/ mine resembles. Certainly no defaults I've ever
seen, anywhere, that's for SURE! But it fits my style well, almost like a
custom fitted glove, now, mostly because it /is/ custom fitted, now, and
that's the important thing for me.
> 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.
You have a good point. But as I said, while that might be the default, a
lot of that can be turned off, now.
And if you're /really/ serious about slimming your resource usage, you'd
be running xfce or lighter, not kde or gnome either one, in any version
(that'll still compile on a modern system, anyway, kde1 and gnome1...
might be light enough, if you could get them to build).
> 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.
CDE-ish shouldn't be an issue. You simply customize it the way you did
kde3. It's still possible. Same with Windows Vista look and feel.
That's purely customizable. And if you keep effects off and do a few
other config tweaks, resource usage shouldn't be terribly much more than
FWIW, I'm on both this list and the kde general and kde-linux lists.
kde3 /is/ likely to get harder to run, over time, so your clock is ticking
on it. When you /do/ decide you've had enough, be that tomorrow or two
years from now, do give kde4 an honest shot before giving up on it. It
really /is/ surprisingly flexible, now, and while the defaults are indeed
quite blingy and resource heavy especially on older graphics hardware, as
I said, I know what it's like to not like any default desktop I've ever
seen, and one of the reasons I continued with kde4 despite all those
problems I had, was that I realized that they /would/ pass, kde4 as it
was /would/ get better, and when it was all said and done, I'd be a whole
lot better off remaining with kde where the policy /does/ favor giving the
user the tools to customize, as compared to desktops where customization
options are actively removed as too complex and confusing for the user.
Each desktop has its users comfortable with that approach, but one thing
that you /cannot/ accurately fault kde for is failing to make available
the customization tools for those who do /not/ find default desktops to
their liking. (At least, not after they get going on a version. Early
kde4 was as pretty much everyone agrees now, simply a mess. 4.4 is a
reasonable release candidate, and 4.5 is honestly the first 4.x version I
can without qualms recommend to pretty much anyone and everyone.)
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