[kde-solaris] kde - solaris 8 -- fixes for artsd.cc and kcmartsrc
attached
Stefan Teleman
steleman at nyc.rr.com
Fri Jul 4 14:17:49 CEST 2003
Attached is artsd.cc with ownership, file descriptors and signal
handler fixes. I am also attaching kcmartsrc for Solaris (which lives
in ${HOME}/.kde/share/config/kcmartsrc).
--Stefan
-----
On Friday 04 July 2003 01:47, Heiko Nardmann wrote:
> 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
> `/opt2/userhomes/nardmann/MeineProjekte/SysAdmin/arts-1.1.2'
> Making all in libltdl
> make[2]: Entering directory
> `/opt2/userhomes/nardmann/MeineProjekte/SysAdmin/arts-1.1.2/libltdl
>' make[2]: Nothing to be done for `all'.
> make[2]: Leaving directory
> `/opt2/userhomes/nardmann/MeineProjekte/SysAdmin/arts-1.1.2/libltdl
>' Making all in mcop
> make[2]: Entering directory
> `/opt2/userhomes/nardmann/MeineProjekte/SysAdmin/arts-1.1.2/mcop'
> /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::basic_ostream<char,std::char_traits<char>
>
> >&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
>
> /opt2/userhomes/nardmann/MeineProjekte/SysAdmin/arts-1.1.2/mcop/.li
>bs/SunWS_cache/CC_obj_5/567_5gKouJinuKDfJLed.o
> std::__RTTI__1nDstdJbad_alloc_
> /opt2/userhomes/nardmann/MeineProjekte/SysAdmin/arts-1.1.2/mcop/.li
>bs/SunWS_cache/CC_obj_C/CM_Spo8A_isexdMcHmI8.o [Hint: static member
> std::__RTTI__1nDstdJbad_alloc_ must be defined in the program]
>
> std::basic_ostream<char,std::char_traits<char>
>
> >&std::basic_ostream<char,std::char_traits<char>
> >
> >::operator<<(std::basic_ostream<char,std::char_traits<char>
> >
> >&(*)(std::basic_ostream<char,std::char_traits<char> >&))
> > .libs/dispatcher.o
>
> void*operator new[](unsigned)
> /opt2/userhomes/nardmann/MeineProjekte/SysAdmin/arts-1.1.2/mcop/.li
>bs/SunWS_cache/CC_obj_4/4ZC2uWjnEigrS7LxyRWy.o
> std::basic_ifstream<char,std::char_traits<char>
> >::basic_ifstream(const char*,int,long) .libs/mcopconfig.o
> std::exception::__vtbl
> /opt2/userhomes/nardmann/MeineProjekte/SysAdmin/arts-1.1.2/mcop/.li
>bs/SunWS_cache/CC_obj_C/CM_Spo8A_isexdMcHmI8.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 program]
>
> std::ios_base::__sync_with_stdio .libs/dispatcher.o
> [Hint: static member std::ios_base::__sync_with_stdio must be
> defined in the program]
>
> std::__RTTI__1nDstdLlogic_error_ .libs/mcopconfig.o
> [Hint: static member std::__RTTI__1nDstdLlogic_error_ must be
> defined in the program]
>
> std::__RTTI__1nDstdIios_baseHfailure_
> /opt2/userhomes/nardmann/MeineProjekte/SysAdmin/arts-1.1.2/mcop/.li
>bs/SunWS_cache/CC_obj_T/TTuPlkkgUghUzDFgT3z_.o [Hint: static member
> std::__RTTI__1nDstdIios_baseHfailure_ must be defined in the
> program]
>
> char*std::basic_string<char,std::char_traits<char>,std::allocator<c
>har>
>
> >::replace(unsigned,unsigned,const
> >:: char*,unsigned,unsigned,unsigned)
>
> /opt2/userhomes/nardmann/MeineProjekte/SysAdmin/arts-1.1.2/mcop/.li
>bs/SunWS_cache/CC_obj_T/TTuPlkkgUghUzDFgT3z_.o
> std::out_of_range::__vtbl
> /opt2/userhomes/nardmann/MeineProjekte/SysAdmin/arts-1.1.2/mcop/.li
>bs/SunWS_cache/CC_obj_T/TTuPlkkgUghUzDFgT3z_.o [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>
>
> >&std::basic_ostream<char,std::char_traits<char> >::put(char)
>
> .libs/dispatcher.o
> bool __Crun::ex_skip()
> /opt2/userhomes/nardmann/MeineProjekte/SysAdmin/arts-1.1.2/mcop/.li
>bs/SunWS_cache/CC_obj_C/CM_Spo8A_isexdMcHmI8.o
> std::logic_error::__vtbl
> /opt2/userhomes/nardmann/MeineProjekte/SysAdmin/arts-1.1.2/mcop/.li
>bs/SunWS_cache/CC_obj_T/TTuPlkkgUghUzDFgT3z_.o [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()
> /opt2/userhomes/nardmann/MeineProjekte/SysAdmin/arts-1.1.2/mcop/.li
>bs/SunWS_cache/CC_obj_T/TTuPlkkgUghUzDFgT3z_.o
> std::__RTTI__1nDstdMout_of_range_
> /opt2/userhomes/nardmann/MeineProjekte/SysAdmin/arts-1.1.2/mcop/.li
>bs/SunWS_cache/CC_obj_T/TTuPlkkgUghUzDFgT3z_.o [Hint: static member
> std::__RTTI__1nDstdMout_of_range_ must be defined in the program]
>
> std::ctype<char>::id
> /opt2/userhomes/nardmann/MeineProjekte/SysAdmin/arts-1.1.2/mcop/.li
>bs/SunWS_cache/CC_obj_T/TTuPlkkgUghUzDFgT3z_.o [Hint: static member
> std::ctype<char>::id must be defined in the program]
>
> std::basic_ifstream<char,std::char_traits<char>
> >::~basic_ifstream() .libs/mcopconfig.o
> std::basic_string<char,std::char_traits<char>,std::allocator<char>
>
> >::__nullref
>
> /opt2/userhomes/nardmann/MeineProjekte/SysAdmin/arts-1.1.2/mcop/.li
>bs/SunWS_cache/CC_obj_M/MPZdkh3qZbzNQ9wud-N2.o [Hint: static member
> std::basic_string<char,std::char_traits<char>,std::allocator<char>
>
> >::__nullref must be defined in the program]
>
> __rwstd::rwse_failbit_set
> /opt2/userhomes/nardmann/MeineProjekte/SysAdmin/arts-1.1.2/mcop/.li
>bs/SunWS_cache/CC_obj_T/TTuPlkkgUghUzDFgT3z_.o [Hint: static member
> __rwstd::rwse_failbit_set must be defined in the program]
>
> void operator delete(void*)
> /opt2/userhomes/nardmann/MeineProjekte/SysAdmin/arts-1.1.2/mcop/.li
>bs/SunWS_cache/CC_obj_C/CM_Spo8A_isexdMcHmI8.o
> __rwstd::except_msg_string::except_msg_string(unsigned,...)
> /opt2/userhomes/nardmann/MeineProjekte/SysAdmin/arts-1.1.2/mcop/.li
>bs/SunWS_cache/CC_obj_T/TTuPlkkgUghUzDFgT3z_.o
>
> ... 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-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: artsd.cc
Type: text/x-c++src
Size: 14467 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-solaris/attachments/20030704/178da5d5/artsd-0001.bin
-------------- next part --------------
[Arts]
AddOptions=
Arguments=\s-F 8 -S 1024 -a sun -d -n -b 16 -m artsmessage -l 3 -f
AudioIO=sun
AutoSuspend=false
Bits=16
DeviceName=
FullDuplex=true
Latency=1
LoggingLevel=3
MessageApplication=artsmessage
NetworkTransparent=true
SamplingRate=0
StartRealtime=true
StartServer=true
SuspendTime=60
X11GlobalComm=true
More information about the kde-solaris
mailing list