[kde-solaris] Re: kde - solaris 8

Stefan Teleman steleman at nyc.rr.com
Fri Jul 4 02:12:59 CEST 2003


Hi Alan!!

I have built KDE 3.1.1 + KOffice 1.2.1 + Umbrello + KXMLEditor + 
QT-3.1.2 + all the additional required libraries (gtk1.2, gtk2.0, 
xine, SDL, Imlib, glade, doxygen, fam, etc, etc), in short, all the 
required additional libraries, with the Sun Forte 7 compiler. You can 
download this from the KDE ftp site (in 3.1.1/contrib/Solaris) -- if 
they are still there. So much for the auto-biographical paragraph. 
:-)

I am now working on porting KDE 3.1.2. As soon as i manage to fix the 
problems in khtml which make it not render fonts (in the KMail mail 
reader window), and which make Konqueror very unstable in web mode, i 
will upload these packages and make them available to everyone.

I would like to say from the outset that none of what i am saying 
below is meant to be read as a criticism of KDE. Had i not been a 
fan, i would not have spent all of my free time from December 2002 
until April 2003 porting, rewriting and fixing code in 3.1.1 to make 
it work on Solaris 8/Forte 7. Now i am spending most of my free time 
trying to find where this khtml problem happens and fixing it for 
3.1.2. :-) 3.1.2 will use FAM instead of filesystem polling. 

About the Sun compiler vs. GCC:

Compared to Forte, in my opinion, gcc is "developmentally challenged" 
-- at least on UltraSPARC. Sun Forte 7 (and 8) are _phenomenal_ 
compilers. GCC has never really been able to generate UltraSPARC 
optimized instructions. Which means, all the performance benefits of 
using v8plusa architecture, instruction pipelining, instruction cache 
prefetch, etc, etc, are just not available with GCC. Also, the GNU 
linker is essentially non-functional on Solaris. It is, and has been 
broken for a very long time. Even the official GNU documentation 
recommends against using the GNU ld and GNU as on SPARC, in favor of 
the Sun native linker and assembler. GCC is fine on Intel (pretty 
much the only compiler available, very few people use the Intel 
compiler, although that one is better than GCC). There are several 
serious drawbacks with GCC, some of which have permeated the overall 
KDE internal architecture.

I am sure you have noticed that KDE makes extensive use of dlopen(). I 
suspect that the reason the KDE architects decided to dlopen() almost 
everything is because GCC is pretty inept at doing symbol relocation. 
Symbol relocation is very slow with GCC, not to mention code 
bloatness. So, to make up for this slowness and bloatness, shared 
objects are being explicitly loaded with dlopen(), instead of relying 
on the run-time linker.

To get KDE to compile on Solaris with Forte 7 (or 8): it is _VERY_ 
difficult. Part of the difficulty is due to this dlopen() business i 
mentioned above. The KDE architecture relies heavily on the following 
implementation pattern: all translation units (*.cpp or *.cc files) 
are built and linked into a shared library (let's call it libfoo.so). 
This library includes the translation unit which contains "main", so 
the 'main' function will be built into this shared library (!). Then, 
an empty  file named "dummy.cpp" (this file does not contain 
anything!) is compiled and linked against libfoo.so, and then, at 
run-time, 'kdeinit' is being called as a placeholder for the program, 
which in turn calls dlopen() on this library, which then fork()'s and 
loads the real executable. All this was done because of GCC's symbol 
relocation problems. This may work ok on GCC, it does _NOT_ work at 
all on Solaris with Forte. It is also a questionable implementation 
practice (in my opinion), for no other reason than it essentially 
forces the implementation of a generic UNIX desktop environment (KDE 
is neither Linux nor GCC) to adhere to the limitations of a 
particular compiler/run-time environment. So, the first thing which 
needs to be done for porting to Forte is to hunt down all the 
instances where this shared library with 'main()' business happens 
(there are so many of them, i would say more than half the executable 
programs in KDE are  built like this), and correct the Makefiles, by 
adding the translation unit containing "main" to the build directive 
of the executable program. Linking against the original libfoo.so is 
then fine, it's just another shared library. Tracking this down is 
very time-consuming, but there is no alternative. For example, 
Knotify, Kicker or Khelpcenter simply do not work at all on Solaris 
with the dlopen() method (you'll get a run-time linker error about 
not being able to find 'main()'. 

There are also a significant number of instances where non-standard 
C++ language constructs which are tolerated by GCC (but not by the 
C++ standard, therefore not by Forte) are being used liberally. These 
all have to be corrected. There are so many instances of this sort, 
it would be pointless for me to try to write them up here. It would 
take me several days. :-)

Many original Makefile.am contain the directive '-z text' for creating 
a shared library (this is done expressily for Solaris). This is 
incorrect. Passing '-z text' to the Sun linker will generate a fatal 
error when, and if, relocatable text references remain against 
non-writeable sections of the object linking against. In other words, 
it's useless. The correct flags for building a shared library on 
Solaris are:

CC -G -h'<library-name>' -z weakextract <full list of fully qualified 
paths to archive libraries containing PIC objects to be built into 
the shared library> <followed by full list of *.o object files to be 
built into the shared library> <followed by any other shared 
libraries to be linked against> -z defs [-z now] -o 
<output-shared-library-name>. The flag '-z now' is optional. It 
disables the lazy load feature of the run-time linker, forcing 
immediate run-time binding of all symbols. It gives a performance 
boost. There is a harder way of building shared libraries, using 
mapfiles, but it's much harder.

Another thing to fix: replacing all calls to the BSD-ish signal(3C) 
interface with the SVR4 (Solaris) sigsetops(3C) API: sigemptyset(3C), 
sigaddset(3C), sigfillset(3C) and sigaction(2). Signal handlers for 
SIGPIPE also need to be added in Solaris (|= SA_RESTART).

For programs which are likely to use sockets, and/or open and close 
many files repeatedly, the number of available file descriptors 
should be increased with setrlmit(2). This is pretty easy to do. The 
following macros should be placed at the top of the translation unit 
containing 'main' (before _any_ #include directives):

#ifdef FD_SETSIZE
#undef FD_SETSIZE
#endif

#define FD_SETSIZE 8192

After which just call getrlimit() and then setrlimit with the new 
FD_SETSIZE assigned to rlim_max inside main() -- always before any 
calls to fork().

I have not posted the sources of my previous (3.1.1) port, mostly 
because it did not seem to trigger much interest from the 'Net 
community, and because i was not able to fix the khtml rendering 
problems. These are the main reasons i did not pursue finding a 
public home for my project. Also, i was too lazy to fix the 
Makefile.am and Makefile.in files (where they had to be fixed), so i 
wrote all my fixes directly in the generated Makefiles. :-) Not the 
right thing to do, but, hey, it worked at the time. :-) I did not 
create any patches because (1) i never found the time to do it and 
(2) the khtml rendering problems in 3.1.1 made me think that i should 
wait with the patches until i fix the problems.

It would be very nice if KDE on Solaris/Forte became 'officially' 
supported at KDE, but there are some code management complexities 
which would have to be addressed (if there is interest). In other 
words: assuming it became officially supported, would Solaris be a 
separate branch, or would it have to be integrated into the main 
source tree. Based on my experience, and contrary to what i 
originally believed, a separate branch seems more feasible and easier 
to manage than a full integration into the main tree.

I do have my .workshop.XO5 and 3 of my 'runConfigure.*' shell scripts, 
which i used to build KDE, and which i am attaching to this message. 
They set CFLAGS, CXXFLAGS and LDFLAGS and the Forte 7 options.

I hope this helps. Please let me know. :-)

--Stefan

-----

On Thursday 03 July 2003 13:32, you wrote:
> Hello Stefan,
> I am subscribed to the kde-solaris mailing list, and I need some
> advice from a kde-solaris expert.
>
> I built kde-3.1.2 with gcc-3.2.2 and binutils-2.13.2.1, and it
> works to some degree, but I always heard that Sun's compiler
> collection produces better executables for Solaris than gcc.
> Why is it that some people say to stay away from gnu's ld and
> others say that it is better than sun's?
> What do you think?
>
> So, I downloaded Sun One Studio 7 (a 60 day demo) and started
> building everything again with this compiler.
> I succesfully rebuilt qt, audiofile, mtools, pcre, libxml, libxslt,
> bzip2, openldap, freetype, libart, sane and xine.
>
> But I of course was unable to build kde. I read in the mailing list
> you've been working to fix kde so it can be build with Sun's cc.
> Do you have any patchs available that I can download to finish this
> task?
>
> Also, I don't know much about Sun's cc, I am using using CFLAGS and
> CXXFLAGS -xarch=v8plusa -xO5 because I want to produce the fastest
> possible binaries. I also read in the man page that there is a
> -fast option, but the more I read the more it scared me.
>
> What CFLAGS and CXXFLAGS do you recommend me to use?
>
> Also, what configure flags do you use with kde?
> I use this:
> --disable-debug --enable-final --enable-shared --enable-mitshm
> --enable-fast-malloc=no --with-xinerama=no
>
> Thanks for reading.
>
> Regards,
>
> Alan

-- 
Stefan Teleman          'Nobody Expects the Spanish Inquisition'
steleman at nyc.rr.com                          -Monty Python
-------------- next part --------------
A non-text attachment was scrubbed...
Name: runConfigure.kdelibs
Type: application/x-shellscript
Size: 1043 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-solaris/attachments/20030704/8c67f8d1/runConfigure.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: runConfigure.kdebase
Type: application/x-shellscript
Size: 1060 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-solaris/attachments/20030704/8c67f8d1/runConfigure-0001.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: runConfigure.kdenetwork
Type: application/x-shellscript
Size: 1065 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-solaris/attachments/20030704/8c67f8d1/runConfigure-0002.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .workshop.XO5
Type: text/x-makefile
Size: 2219 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-solaris/attachments/20030704/8c67f8d1/workshop.bin


More information about the kde-solaris mailing list