[kde-solaris] Re: kde - solaris 8

Heiko Nardmann h.nardmann at secunet.de
Fri Jul 4 08:47:24 CEST 2003

Hash: SHA1

I tried to compile 3.1.2 some weeks ago, too.

The arts package fails with the following message:

make  all-recursive
make[1]: Entering directory 
Making all in libltdl
make[2]: Entering directory 
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory 
Making all in mcop
make[2]: Entering directory 
/bin/bash ../libtool --silent --mode=link --tag=CXX CC      -o libmcop.la 
- -rpath /usr/local/pkg-arts-1.1.2/lib -no-undefined -version-info 1:0 
buffer.lo connection.lo core.lo dispatcher.lo iomanager.lo object.lo 
socketconnection.lo tcpconnection.lo unixconnection.lo tcpserver.lo 
unixserver.lo objectmanager.lo factory.lo idlfilereg.lo ifacerepo_impl.lo 
mcoputils.lo startupmanager.lo md5.lo md5auth.lo referenceclean.lo 
datapacket.lo asyncstream.lo notification.lo flowsystem.lo extensionloader.lo 
tmpglobalcomm.lo mcopconfig.lo connect.lo reference.lo type.lo trader_impl.lo 
dynamicrequest.lo anyref.lo loopback.lo debug.lo delayedreturn.lo thread.lo 
dynamicskeleton.lo -lsocket  -lnsl ../libltdl/libltdlc.la
Undefined                       first referenced
 symbol                             in file
>&std::operator<<(std::basic_ostream<char,std::char_traits<char> >&,const 
char*) .libs/dispatcher.o
int std::basic_string<char,std::char_traits<char>,std::allocator<char> 
>::compare(unsigned,unsigned,const char*,unsigned)const 
[Hint: static member std::__RTTI__1nDstdJbad_alloc_ must be defined in the 

>&(*)(std::basic_ostream<char,std::char_traits<char> >&)) .libs/dispatcher.o
void*operator new[](unsigned)                       
std::basic_ifstream<char,std::char_traits<char> >::basic_ifstream(const 
char*,int,long) .libs/mcopconfig.o
[Hint: try checking whether the first non-inlined, non-pure virtual function 
of class std::exception is defined]

std::__RTTI__1nDstdMlength_error_ .libs/buffer.o
[Hint: static member std::__RTTI__1nDstdMlength_error_ must be defined in the 

std::ios_base::__sync_with_stdio .libs/dispatcher.o
[Hint: static member std::ios_base::__sync_with_stdio must be defined in the 

std::__RTTI__1nDstdLlogic_error_ .libs/mcopconfig.o
[Hint: static member std::__RTTI__1nDstdLlogic_error_ must be defined in the 

[Hint: static member std::__RTTI__1nDstdIios_baseHfailure_ must be defined in 
the program]

>::replace(unsigned,unsigned,const char*,unsigned,unsigned,unsigned) 
[Hint: try checking whether the first non-inlined, non-pure virtual function 
of class std::out_of_range is defined]

>&std::basic_ostream<char,std::char_traits<char> >::put(char) 
bool __Crun::ex_skip()            
[Hint: try checking whether the first non-inlined, non-pure virtual function 
of class std::logic_error is defined]

std::logic_error::~logic_error()         .libs/mcopconfig.o
void __Crun::register_exit_code(void(*)()extern"C") .libs/mcoputils.o
void __Crun::ex_chk_unexpected()  
[Hint: static member std::__RTTI__1nDstdMout_of_range_ must be defined in the 

[Hint: static member std::ctype<char>::id must be defined in the program]

std::basic_ifstream<char,std::char_traits<char> >::~basic_ifstream() 
[Hint: static member 
>::__nullref must be defined in the program]

[Hint: static member __rwstd::rwse_failbit_set must be defined in the program]

void operator delete(void*)                       

... and so on ...

Did you experience these problems, too?

Have you been able to fix them?

Here is my compiler version:

CC.bin: Forte Developer 7 C++ 5.4 Patch 111715-07 2003/04/13

On Freitag, 4. Juli 2003 07:12, Stefan Teleman wrote:
> 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-, 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

- -- 
Heiko Nardmann (Dipl.-Ing.), h.nardmann at secunet.de, Software Development
secunet Security Networks AG - Sicherheit in Netzwerken (www.secunet.de),
Weidenauer Str. 223-225, D-57076 Siegen
Tel. : +49 271 48950-13, Fax  : +49 271 48950-50
Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)


More information about the kde-solaris mailing list