Home [ade] cookies

*sniffle* (2)

Another week gone by an no end to my cold in sight. This is getting to be really annoying, as it both fragments my work day and makes me unreliable in responding to just about anything — so various jobs (both real and hobby) have been falling behind.

The hobby bits are easier to write about, so here goes: I wanted to produce a screenie of Krita on OpenSolaris, but it turns out that it hand not been built in my first packaging (neither had KSpread, for that matter). Turns out they require Eigen. Eigen is a C++ template-based linear algebra library. So I installed the Eigen package (also produced by the KDE4-OpenSolaris project: make no mistake, this is a small group with a big software stack to take care of). That’s where the fun starts — I don’t think anything else makes serious use of Eigen. Maybe some stuff in KDEgames or KDeedu, but obviously because I hadn’t had Eigen installed previously, they (if they are there) have been silently ignored.

So, Eigen. Since the KDE4-OpenSolaris project aims to use the Sun Studio compiler (so that the resulting KDE4 could be included in the base system and so that i t can re-use any other C++ infrastructure in the system), we need to make sure that Eigen works with the compiler. In the case of a giant and complicated template library, that can be a big effort. And I’m immediately stymied by the Matrix class, where the compiler complains about multiple definitions of every type in the Eigen generic interface (Base, Scalar, and another half-dozen). I’ve not even managed to strip the examples down to an example that demonstrates the problem, which makes debugging — or asking the compiler gurus for help — difficult.

Suffice to say that Krita screenshots are not to be expected anytime soon.

On the upside, the release of KDE SC 4.4 RC2 means that the other bits are nearing stability, which means we can re-focus on stability and performance on OpenSolaris for a bit. Since Pavel has set up various continuous builds on our crunchy build box (courtesy of Sun Netherlands) so tracking in future should work a little better — I hope we have fewer separate patches to maintain in future as more stuff gets upstreamed.


6 Responses to “*sniffle* (2)”

  1. Benoit Jacob Says:


    Fortunately one of us reads planetkde, otherwise we’d have missed your blog…

    Eigen does support Sun CC but only in the development branch, not in 2.0. I’ve just edited the wiki to clarify this.

    If you want to backport Sun CC support to 2.0, you’re welcome to do so :)

    Given that Sun CC is a proprietary compiler, with a C++ support that differs greatly from the major compilers (see in the commit history all the effort it took to support in the development branch) and a very small market share, my motivation to do it myself is not high, but I’ll probably accept a patch back-porting it ;)

  2. Benoit Jacob Says:

    Note: Sun CC support in the development branch is entirely Gael’s work, in case my previous answer might sounds like I did it.

  3. adridg Says:

    That’s cause you guys rock. If a lot of the porting in the dev. branch was due to Sun’s ancient and broken STL, then, unfortunately, there’s an updated, 2009-dated, gcc-STL-compatible C++ STL now in OpenSolaris, and that’s the one that we actually use for all of our KDE building. So I *hope* you didn’t stick a ton of work into that. As far as “differs greatly”, well, that’s because it’s a stickler for the C++ standard, instead of just eating what everyone throws at it (I might characterize g++ as the IE5 of C++ compilers, but that might be overly unfriendly).

  4. Benoit Jacob Says:

    Argh, your blog parsed C++ code as HTML, retrying… if that works, just don’t publish the previous version.

    Hm, looking at the changes that Gael made to support sun studio:
    – only a small minority of them have anything to do with the STL (which we use very little).
    – some are indeed general C++ compliance fixes
    – some are working around plain bugs in Sun studio, for example in changeset 492b72d526ee:

    + // workaround sun studio:
    + LhsIsVectorAtCompileTime = ei_traits::ColsAtCompileTime==1 || ei_traits::ColsAtCompileTime==1,
    value = ei_is_diagonal::ret || ei_is_diagonal::ret
    ? DiagonalProduct
    : ei_traits::MaxColsAtCompileTime == Dynamic
    && ( ei_traits::MaxRowsAtCompileTime == Dynamic
    || ei_traits::MaxColsAtCompileTime == Dynamic )
    - && (!(ei_traits::IsVectorAtCompileTime && (ei_traits::Flags&RowMajorBit) && (!(ei_traits::Flags&DirectAccessBit))))
    - && (!(ei_traits::IsVectorAtCompileTime && (!(ei_traits::Flags&RowMajorBit)) && (!(ei_traits::Flags&DirectAccessBit))))
    + && (!(Rhs::IsVectorAtCompileTime && (ei_traits::Flags&RowMajorBit) && (!(ei_traits::Flags&DirectAccessBit))))
    + && (!(LhsIsVectorAtCompileTime && (!(ei_traits::Flags&RowMajorBit)) && (!(ei_traits::Flags&DirectAccessBit))))
    && (ei_is_same_type<typename ei_traits::Scalar, typename ei_traits::Scalar>::ret)
    ? CacheFriendlyProduct
    : NormalProduct };

    What we have here is that Sun Studio is confused by using a member enum from a another templated class in a complex expression and the work-around consists in reimplementing here this enum as a local enum.

    There’s another similar example in changeset 01a0c8cb5807:

    + _HasDirectAccess = (int(Flags)&DirectAccessBit) ? 1 : 0 // workaround sunCC

    Another kind of problem is:

    - typedef typename ei_unref::type _MatrixTypeNested;
    + typedef typename ei_cleantype::type _MatrixTypeNested;

    Here, ei_unref strips any ‘&’ in a type, and ei_cleantype strips both ‘&’ and constness. The fact that this change made Sun CC happy means that Sun CC has a problem with understanding that typename (const C)::T is the same thing as typename C::T. Which, I’m not 100% sure, but probably is standard behavior.

  5. Benoit Jacob Says:

    In any case, characterizing g++ as “the IE5 of C++ compilers” is not something I can agree with. G++ with -Wall -Wextra -pedantic (as we compile Eigen’s unit tests with) is pretty strict. If you want to call any compiler “the IE5 of C++ compilers”, it would rather have to be MS visual studio, which is far far more permissive and doesn’t have such strictness options. Porting code from G++ (with strictness options) to MSVC is a mostly a matter of working around MSVC bugs. Porting code from MSVC to G++ is mostly a matter of adhering to the C++ standard.

  6. adridg Says:

    You;re right it was an uncharitable characterization of gcc by me. Unfortunately, not everyone *does* use those strict options, so you end up with sloppy code in the KDE codebase. However, I’ll stop claiming Sun Studio is a nice standards compliant compiler — maybe we can file compiler bugs in order to solve the issues it causes for Eigen. In the meantime, I’ll see if I can package up the current devel version (yay, Mercurial!)