[kde-solaris] Re: kde - solaris 8
Achim Bohnet
ach at mpe.mpg.de
Fri Jul 4 11:15:02 CEST 2003
On Fri, Jul 04, 2003 at 01:12:59AM -0400, Stefan Teleman wrote:
> Hi Alan!!
Hi Stefen,
Thanks for this very interesting message!! Your work is very much
appreciated.
>
[...]
>
> 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.
That's true for the kdeinit trick: let kdeinit load and reloacate the
most shared libs and dlopen the app as shared lib. Boosted stuff on
intel due to missing features on gnu ld and g++. Looks like it is
unfortunately the reason for the headache with Solaris/Forte.
On the other Hand: kparts, plugins, applets (e.g. for kicker) use also
dlopen but here the reason is extendability. to support unlimited
features not known at compile/link/startup time.
>
> 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
Sad but true. Nevertheless it made most of linux users whining
about slow startup time. Looks like solaris users didn't wine loud
enough about the drawback of lack of portability :(
> 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()'.
Long time ago Stefan Coolo, father of unsermake and KDE .am guru (IMO)
commited sporadically fixes to keep KDE running on KDE Solaris. By
accident AFAIR he's also release coordinator for KDE 3.2.
Looks like a solid base for help/assistance to get your fixes/patches
into KDE cvs. I'll suggest post your message with some example fixes
on kde-devel (or kontact coolo directly asking for kde-core-devel
membership and post there if kde-devel is too high volume for you).
I'm sure you and kde developers can find an automated way to
support both, the kdeinit trick and 'normal' binary support without
too much hassle for the kde developer creating kde apps.
> 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. :-)
Same is/was true with cxx on Alpha/Tru64 Unix. Tom Leitner commit
dozens of fixes for gcc'ism to get cxx builds. General
c++ portability fixes will be accepted to make forte happy are
no problem to get into KDE (otherwise activate the kde-solaris
community;) After someone checked in several patches for you
he will automaticly ask for an kde cvs account so you can do it
yourself.
>
> 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:
One word: coolo ;)
>
> 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.
Hey, it's free software. If someone doing the work (and you did
already most of it!!) there no reason why this should not happen.
Full integration has a stepper curve but it much better on the long
run. Intergration of an -disalbe-kdeinit-trick is an investment in
the future (whenever binutils/gcc/ld are able to handle relocations
much better) ;)
>
> 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. :-)
Thx again for your work!! Hope to see some KDE cvs checkin by
you soon ;)
Achim
>
> --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
> ___________________________________________________
> This message is from the kde-solaris mailing list.
> Account management: http://mail.kde.org/mailman/listinfo/kde-solaris.
> Archives: http://lists.kde.org/.
> More info: http://www.kde.org/faq.html.
More information about the kde-solaris
mailing list