[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