[kde-solaris] [kde-discuss] Gentle Question

Kunal Deo Kunal.Deo at Sun.COM
Tue May 6 13:00:29 CEST 2008

Hi Michael
Thanks for the suggestion, I'll do that.

My reason for choosing GCC over Sun Studio:
1. I am coming from Linux background and feel more comfortable when 
using gcc.  However, I'm still linking to Sun ld (to maintain 
compatibility with existing Solaris binary)

Using built-in specs.
Target: sparc-sun-solaris2.10
Configured with: ./configure --with-gmp=//source/kde4/ 
--prefix=/source/kde4/ --with-ld=/usr/ccs/bin/ld --enable-languages=c,c++
Thread model: posix
gcc version 4.3.0 (GCC)

2. I feel like cmake works as a charm when used with gcc. Than any other 

3. If I ran into problems. I can always search on gcc mailing list which 
covers virtually everything and also other projects  using gcc like 
mysql and so on. (There are many)

4. I prefer Kdevelop as my IDE and it is easy to generate KDevelop 
project files when using cmake.

5. gmake can run parallel compilation, upto 16 on multi-core processor. 
Mine is 16x2 cores. So it is fast with gamke -jx option. where x is the 
number of cores.

6. Fancy stuffs (i like it) like color gcc output are plus.

Sometime in future  I planning to come up with performance metrics for 
KDE4 with gcc.

Michael Schuster wrote:
> Kunal Deo wrote:
>> Hi Stefan
>> Thanks for your quick response. I understand the reason to support  Sun 
>> Studio.  But KDE offcially supports GCC 4.x series. Thats why I've 
>> decided to use gcc. Moreover toolchain has been ported as well. I've 
>> ported almost everything and its running fine. KDE4 is in progress.
>> I did run into few problems but I've fixed that (including compilation 
>> of strigi)
>> 1. GCC 4.3 error where it doesnt compile functions like strcpy() 
>> memset(), but works when you add "include <cstring>"
>> 2. Linking problems when you use POSIX calls which are not system calls 
>> in solaris but are general library, classic example is
>>   sched_setscheduler() which can be fixed by using -lrt and so on.
>> So far the performance has been very good. And runs quite comfortability.
>> Let me know your thoughts.
> good to know it worked. It might be interesting for others if you could 
> publish in detail (maybe on a blog ... ) what you had to do to get this 
> going.
> If your whole intention in this project was to get KDE4 running on 
> Solaris, congratulations.
> I do wonder though what you're trying to achieve in the long run (if you 
> do at all) ... or are you satisfied with a one-off success?
> - Will you (or a team following your lead) be prepared to maintain 
> whatever set of tools/sources/receipes is necessary so you can keep up 
> with KDE4 on Solaris changes with gcc?
> - Will you go to the (probably not insignificant) effort to modify the 
> build infrastructure to build with both Sun Studio and gcc?
> - Might it not be more worthwhile in the long run to invest your time 
> and apparent skill into helping out with the ongoing effort of building 
> KDE4 on Solaris with Sun Studio?
> regards
> Michael
>> Stefan Teleman wrote:
>>> On Mon, May 5, 2008 at 1:55 AM, Kunal Deo <Kunal.Deo at sun.com> wrote:
>>>>  Hi Stefan
>>>>  Thanks for the reply. I wanted to know why GCC is not supported for KDE4.
>>>> So far I have compiled everything except strigi and hope I will do that
>>>> also.
>>> There are several reasons:
>>> 1. For KDE4 on Linux (and even for KDE3), there are restrictions as to
>>> which versions of GCC are supported -- some versions of GCC are known
>>> to miscompile KDE.
>>> If we start introducing additional complexities with supporting GCC on
>>> Solaris, then we have to reconcile the GCC version restrictions on
>>> Linux and FreeBSD with the GCC version restrictions on Solaris. Noone
>>> has the time to determine which versions of GCC are OK across all 3
>>> platforms.
>>> 2. GCC does not have a stable C++ ABI. GCC's C++ ABI has changed
>>> several times between GCC releases, and simply stating "GCC is
>>> supported" is misleading: only C++ ABI compatible versions of GCC
>>> would be supported.
>>> 3. Sun PSARC rules require that any C++ software available in
>>> Solaris/OpenSolaris, which exposes public API's, must be built with
>>> Sun Studio, and with the Sun C++ ABI Version 5. PSARC/2002/348 (ICU)
>>> is publicly available at opensolaris.org (the PSARC case which
>>> enforces this requirement).
>>> [1] and [2] simply introduce too much complexity. [3] is a hard
>>> requirement: we must support Sun Studio.
>>> You can still try to build KDE4 with GCC. However, you will run into
>>> problems. There will be "unsupported GCC Version" problems, and there
>>> is already C++ software in Solaris/OpenSolaris which has been built
>>> with Sun Studio, and which is used by KDE4 (examples: PCRE, OpenEXR,
>>> and more). Sun Studio C++ ABI and GCC C++ ABI are not compatible with
>>> each other. You will not be able to link the already present C++
>>> Solaris software with GCC.




More information about the kde-solaris mailing list