For the first time ever, KDE is available for SPARC Solaris compiled with Sun's own Forte compilers. Thanks to the hard work of Stefan Teleman you can download Solaris packages here. Read on for details as to how the Sun Forte port began and how KDE finally managed to get a maintainer for its Solaris packages. Those of you with an interest in Solaris and KDE may also wish to subscribe to the kde-solaris mailing list.
KDE 3.1.3 on Solaris built with the Sun Forte compilers is out
Stefan TelemanFirst off, many thanks to Eva Brucherserifer, Dirk Mueller,
and to everyone at KDE and the KDE Solaris community for their
kind support.
This project of mine has been a long time in the making. I started
thinking about it about one year ago, during a brunch with one of
my very good friends. I had taken the subway to Park Place, Brooklyn
to meet him for brunch, on a hot late July Saturday. He, and
his family were going back to France, so this was going to be
one of the last times we could hang out.
At the time, I was looking for the "next thing" to do. I had been
using KDE for a while, on Linux, and the idea popped in my head,
what if it were available for Solaris with the native Sun compiler.
I remembered seeing a 2.2 gcc version on someone's Sun box at work
about a year earlier.
So, while chatting at brunch, i mentioned to Seb "what if i ported
KDE to Solaris with the Sun compiler". His initial reaction was:
"You're crazy. Do you realize the time commitment. What if it can't
be done." I was actually asking myself the exact same questions.
Three weeks went by, we met again for brunch. This time around i
didn't mention anything about KDE. Out of the blue, he asked me:
"what about KDE." i said "i'm going to do it. Sun is selling
refurbished workstations on eBay. i ordered one yesterday". He
didn't say anything, but i could tell what he was thinking.
That was at the end of August 2002.
The box didn't show up until late October, and i started working
on KDE in November 2002. It was a clean slate start. My idea was
to build everything with Forte, including the additional libraries,
in order to get the best performance on Sparc. I also knew from
previous experiences that mixing compilers (gcc and SunProCC) does
not really work well.
It took me 6 months to get the first workable release out (3.1.1,
April 2003). A lot of work went into it, all of it done in the
evening and on weekends. Wasn't anywhere near fully functional,
but it mostly sort of worked. Except html rendering and multimedia.
I kept working on 3.1.2 trying to find out where the html rendering
problem was. Dirk Muelller ssh'ed to my Sun box in New York City from
Germany and we debugged kthml together.
3.1.3 came out pretty nicely. It's fast, it's very stable and Keramik
looks beautiful. It's truly the best desktop.
I am trying to get another Sun box with Solaris 9, which comes with
XRender and XFreeType. As soon as that happens, i will make KDE
available for Solaris 9 as well.
My plans for 3.2: kdemultimedia to work, and write a friendly
installation program. And one more thing: ask my doubting friend how
KDE Solaris is working for him. :-)
Comments:
kdenonbeta/nonlinux - Marcus Camen - 2003-09-23
Ah, that's great. Congrats!
BTW:
We have just created
kdenonbeta/nonlinux/patches/hpux
So feel free to put any additional patches, howtos, compiler options or whatever in kdenonbeta/nonlinux/patches/solaris.
Re: kdenonbeta/nonlinux - ac - 2003-09-24
Why do you need a module for that? Can't you put it in KDE CVS HEAD?
Re: kdenonbeta/nonlinux - George Staikos - 2003-09-24
They are mostly for problems with the compiler and shouldn't go into the mainline. They will be reviewed and if suitable for the mainline, they will go in over time.
great news! - Mark Hannessen - 2003-09-23
Solaris 9 KDE would be nice.
Solaris is a quite stable OS but i really hated the UI.
KDE surely is a good thing for Solaris.
And it is just more proof of open source portability.
nice work guyes !
gcc3.x vs forte - Anonymous - 2003-09-23
How does it compare to KDE compiled with gcc3.x on solaris? Any speed boost?
Good thing.... - Debian User - 2003-09-23
Hi,
it's always a good idea to get things working on as many compilers as possible. You get better code quality and even catch undiscovered bugs doing that.
Did anybody compile KDE with icc yet?
Yours, Kay
very interesting - Anton Velev - 2003-09-23
Hello,
This is very interesting experience.
I am interested to know making KDE compile without GCC but with the OS native compler does it lead just to C++ code related issues or also replacing some glibc dependency with the libs that Sun provides?
Congrats,
Anton
Why was this so hard? - Otter - 2003-09-24
I appreciate the work but I'm surprised it was such a major undertaking. Shouldn't the code be at least as portable between compilers as it is between platforms? Does automake/autoconf or some other part of the build system have a problem with Forte?
Re: Why was this so hard? - George Staikos - 2003-09-24
Most of the problems tend to be due to broken C++ compilers. I don't think I've met a non-broken C++ compiler. :-) GCC seems to be one of the best now though.
Re: Why was this so hard? - Stefan Teleman - 2003-09-25
The problems are not with SunProCC, all the problems were caused by non-standard GNU/GCC-isms which are abundant in KDE. They may make code writing somewhat easier, but they make porting to strict compilers very difficult.
SunProCC 7 and 8 track the C++ standard very closely.
For those who doubt this statement, please visit:
http://www.jamesd.demon.co.uk/csc/faq.html
and note the email addy of the Chairman of the ANSI/ISO C++ Standard Committee.
The performance improvement on SPARC using SunProCC is 2.5-3x over gcc.
--Stefan
Re: Why was this so hard? - Nick - 2003-09-24
You've obviously never had to port some C++ code from one Unix to another. It's a black art which can leave you very frustrated and unsure of how to proceed. Apart from Compiler differences you also have to deal with different underlying libc implementations and posix calls changing. Plus some compilers define things using built-ins rather than include files. It's something you get better at with practice but it's by no means trivial.
Re: Why was this so hard? - Otter - 2003-09-24
I've been working with the native KDE on MacOS X project, so I definitely realize how hard moving between platforms can be. But this is a case where the code has already been ported to the new Unix. I'm surprised that then switching to a new compiler was so difficult.
I'm not arguing with or insulting the guy who did it -- just expressing surprise that there were so many obstacles.
Re: Why was this so hard? - Nick - 2003-09-29
The problem is when you switch compiler you switch a lot of other things without realising it. The libc will almost certainly change as does the C++ STL library implementation you are using. Your linker will change and your assembler. Lots of compilers implement certain functions as built in as well. Porting to a different compiler can be harder than porting to different hardware.
Re: Why was this so hard? - Philip Brown - 2003-09-24
The problem is that the KDE developers seem to like to use the latest C++ "features" instead of keeping it simple. So the compiler has to be fully up to date with the latest C++ featurecreep spec, or things dont go too well.
There is lots and lots of C++ code out there that has no problems with sun forte C++. even the old 6.2 release. But QT +KDE is a nightmare with it.
actually usable? - jmk - 2003-09-24
As sparcs aren't that state of the art CPUs, how fast is it? Usable with 400MHz/192MB U5 WS?
Re: actually usable? - Andras Mantia - 2003-09-24
I had KDE 2.x on a Sparc 4 (175Mhz, ~128MB memory), compiled with g++ some years ago and it was slow, but usable. But I admit, that I compiled it on an UltraSparc server... Later I got an Ultar5 which was around 400-500Mhz and 256MB RAM and that was quite OK. See my experience about it on http://developer.kde.org/build/solariscompile.html, just don't ask me for the X11 headers as I don't have them anymore (notice the date at the top!)
With the native compiler I would expect to see faster code and less compilation time, but I may be wrong.
Andras
Re: actually usable? - Stefan Teleman - 2003-09-25
KDE was built for UltraSPARC specific v8plusa ISA with aggressive cache prefetch and O5 optimized code.
--Stefan
SUNWkderequired - Lasse Aagren - 2003-09-25
This sure is a great job done. But I have one question. While KDE and qt is placed in the /opt tree, the software from SUNWkderequired is placed in the /usr/local tree. Why not put this in the /opt tree too? I maintain a /usr/local structure I wouldn't like to 'taint'. If the SUNWkderequired package had a base like /opt/KDErequired most people would be able to useit without 'tainting' an existing system.
Re: SUNWkderequired - Stefan Teleman - 2003-09-25
I know that the required libraries can cause this problem for
existing installations in /usr/local. The problem is that these
packages have to be installed somewhere, and putting everything
in /opt might cause the partition to fill up. The other thing is,
no matter where the pkg would default its root install, there
will always be the chance that one cannot use that particular tree.
Unfortunately, there's no easy win in this. :-)
You can relocate a Sun pkg with pkgadd -R. If you do that, you need
to do a little bit of hacking of the *.la files and of your ld.so:
1. replace all instances of the string '/usr/local' in the KDE *.la
files with the relocated path (i.e. '/opt/kderequired').
2. create an alternate ld.so cache and an alternate LD_CONFIG file
for the shared libraries which used to reside in /usr/local --
use crle(1) to do this
3. define the relocated directory as a trusted directory for ld.so -- also
use crle
4. explicitly set LD_CONFIG at the top of startkde to this new ld.so.config
file.
I realize this is painful, but, no matter where i place these libraries,
there will always be someone who cannot use that directory and needs to
relocate.
I promise that installation for 3.2 will be a lot less painful. :-)
--Stefan
Re: SUNWkderequired - Lasse Aagren - 2003-09-25
Thanks for the answer. I'll try your solution.
But for the sake of the debate :)
I think that /usr/local is a tree which most people uses in some kind ore another, so dropping files here are likely to conflict with something.
You say that /opt might fill up. This can be solved by simple symbolic links to another location which hold enough space. And by giving the package a unique /opt/SUNWsomething root it will most likely not conflict with anything. Just my two bits :)
aagren
Should be called CSWkde - Anonymous - 2003-09-26
The packages really should be named CSWkde since they're not packaged by Sun.
Cheerio.
Re: Should be called CSWkde - Stefan Teleman - 2003-09-26
These packages are not CSW.
The naming convention is the one recommended by
Sun Microsystems in their Answerbook collection,
"Building Packages".
Cheers.
--Stefan
Re: Should be called CSWkde - Anonymous - 2003-10-01
Can you point to what you're referring to with a URL?
If my understanding is correct, CSW = Contributed Software for which
this is contributed on top of Sun's SUNW packages (prefix SUNW).
This guy has the right idea:
http://www.blastwave.org/packages.php/kdebase_gcc
Please clarify.
Re: Should be called CSWkde - Stefan Teleman - 2003-10-01
> Can you point to what you're referring to with a URL?
I can point you to the AnswerBook Collection which is available
on Solaris, if installed. Search for "Building Packages". If you
do not have AnswerBooks installed, you may search on Google for
something available.
> If my understanding is correct, CSW = Contributed Software for which
> this is contributed on top of Sun's SUNW packages (prefix SUNW).
No. This is blastwave's packaging standard. The KDE packages were not
released through blastwave, nor were they packaged for blastwave. There
is no relation or connection whatsoever between the packages available
at KDE and blastwave. These packages were built by me, specifically for
KDE, and they were kindly made publicly available by KDE.
The /opt/csw tree is reserved by blastwave, and so is the 'CSW' package
prefix. KDE software installs under /opt/kde*.
Whether or not i choose to release KDE packages through blastwave,
in addition to the KDE packages, it is something to be decided
in the future, and that will only happen with KDE's consent. At that
point in time, packages released through blastwave will most likely
observe blastwave's package naming standards.
> This guy has the right idea:
> http://www.blastwave.org/packages.php/kdebase_gcc
read my comments above.
Are all the things in SUNWkderequired really req'd - Grant McDorman - 2003-10-03
I'm in the process of installing the packages. However, I'm shocked at the size of the SUNWkderequired package - and some of the things in it. Do we really need Opera, AfterStep, BlackBox, pico, pine, xv, and more to run KDE? - I don't have those things installed on my Linux system at home, and KDE runs just fine, thank you.
Trimming out some of the stuff like this should help with the size, no?