Summary: | kde-base/korganizer-3.5.9 build fails | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Vasilis Lourdas <bugs> |
Component: | [OLD] KDE | Assignee: | Gentoo KDE team <kde> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | alonbl, ansla80, bob, davide.angelocola, dirk, dkarasik, gentoo, m.debruijne, matej, micmicsh, nbkolchin, thomas.kear |
Priority: | High | ||
Version: | 2007.0 | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Vasilis Lourdas
2008-02-21 19:59:35 UTC
"kdeenablefinal - EXPERIMENTAL: KDE ebuilds will use the enable-final flag, yielding compilation speedups at the cost of heavy mem usage and potentially causing problems. We strongly discourage setting this" We'll fix this properly but please get rid of the "kdeenablefinal" USE flag. It's pretty much useless anyway. (In reply to comment #1) > "kdeenablefinal - EXPERIMENTAL: KDE ebuilds will use the enable-final flag, > yielding compilation speedups at the cost of heavy mem usage and potentially > causing problems. We strongly discourage setting this" > > We'll fix this properly but please get rid of the "kdeenablefinal" USE flag. > It's pretty much useless anyway. Disabling it for korganizer and yes, it emerges. Byt why disable kdeenablefinal? It's supposed to speed up compilation times, right? (In reply to comment #2) > Disabling it for korganizer and yes, it emerges. Yes, upstream broke it. > Byt why disable kdeenablefinal? It's supposed to speed up compilation times, > right? Yes, it's *supposed* to but I've yet to see it do much good with respect to compilation speed. It *eats* RAM and if you're unlucky, swapping that might occur will make compilation take even *longer*. Furthermore, the code must be suitable for that and, as you experienced, it isn't always. (In reply to comment #3) > > Byt why disable kdeenablefinal? It's supposed to speed up compilation times, > > right? > > Yes, it's *supposed* to but I've yet to see it do much good with respect to > compilation speed. It *eats* RAM and if you're unlucky, swapping that might > occur will make compilation take even *longer*. Well, all my KDE 3.5.9 packages compiled fine with this USE flag enabled, except for korganizer. However, I cannot say I am low on RAM, it's been a week since my upgrade to a new system with 4GB of RAM, so I'll probably leave it enabled for now. Thanks for your input. > Furthermore, the code must be suitable for that and, as you experienced, it > isn't always. Right. What about kdehiddenvisibility? I also have this enabled, should I disable it? Where USE="kdeenablefinal" helps over the compilation speed has got to do with some of the linking inefficiencies of GCC. Since larger blocks of code is handled by the compiler, it can do better inter-procedural optimizations since it knows more about how the functions are called, etc... The benefit is more of a size benefit (several KB smaller executables), the supposed execution speed benefit is practically unmeasurable. Thanks for your input Nickolas. Since smaller compilation times is by itself a benefit, I will have this flag enabled. When (if) a KDE package build fails, I will disable it and see if it still fails. It fails for me and I do *NOT* use kdeenablefinal flag. (In reply to comment #7) > It fails for me and I do *NOT* use kdeenablefinal flag. > Ahhh, sorry - kdeenablefinal flag is enabled but I'm pretty sure I didn't enable it... I'm going to try it without this flag. Yup, it's ok. Upstream bug 158244. *** Bug 211235 has been marked as a duplicate of this bug. *** *** Bug 211346 has been marked as a duplicate of this bug. *** Finally fixed in CVS. Thanks for the report. |