[kde-solaris] status on kde3.1

Stefan Teleman kde-solaris@mail.kde.org
Fri Feb 14 06:00:01 2003


Hi!

To begin, i would like to thank everyone for their kind and supportive 
replies. I am very very happy to work on this project.

As far as my build environment at home goes:

Sun Ultra 60 2x 360MHz UltraSPARC IIi 2GB RAM
Elite 3DM6 graphics board
SunOS starwars 5.8 Generic_108528-18 sun4u sparc SUNW,Ultra-60
Forte-7 with patches (32-bit)
Forte-7 flags:
-features=%all,extensions -instances=extern -library=Crun,Cstd 
-template=wholeclass,extdef -verbose=template -xO3 -xtarget=ultra2 
-xarch=v8plus -dalign -xprefetch=yes -xlibmopt -mt -D_REENTRANT

What i have finished porting and i am currently running:
qt-x11-free-3.1.1
arts-1.1
kdelibs-3.1
kdebase-3.1
kdenetwork-3.1
kdemultimedia-3.1
kdebindings-3.1
kdeaddons-3.1
kdeadmin-3.1

Non-KDE packages:
kbear-2.1 (works very very well)

What i am currently working on:
kdegraphics-3.1
kdegames-3.1

Additional libraries:
libpng-1.2.5
libmng-1.0.0
libjpeg-6.2.0
libtiff-3.6.0
libxml and libxslt (Gary Pennington's port)
libpango-1.0
libglib-2.2.1
libatk-1.0
libgdk-2.2.1
libgtk-2.2.1
libfreetype-6.3.2
libxine-1.0beta4

I have built (and in some cases ported the code here and there for 
minor fixes) all these additional libraries with Forte-7.0 on my Sun 
box, since i want to provide a clean and consistent KDE release. My 
plan is to package all the required extra libraries into a separate 
package (calling it requiredlibs or something), so everyone can use 
the fully consistent build.

Yes, i would definitely like to have these fixes incorporated into the 
main source tree, no question about it. I wouldn't want to cause a 
code branch in KDE, since that quickly becomes so difficult to 
maintain and merge.

A lot of the fixes pertain to declaring and implementing 
bool::operator==(const T& t) const and
bool::operator< (const T& t) const, for those types which are used in 
containers (std::list<T> and QValueList<T>) -- the compiler does not 
generate these operators automatically (nor is it required to :-). In 
some cases, the operators were declared and implemented non-const, so 
the compiler rejected them. Many other fixes came down to my  
implementing the sigaction(2) interface for signal handlers, as 
opposed to the original implementation with BSD-ish signal(3C), which 
Forte does not like very much in C++ (had to write the whole song and 
dance extern "C" signal handler function and function pointer and so 
on)..

A lot of problems in khtml/* (and elsewhere) were caused by GCC's 
-foverloaded-virtual flag, which is not available on Forte, and 
because of which, many member functions were not declared virtual 
when they should have been, or they were declared virtual in a leaf 
inherited class, and not starting at the base. This lead to run-time 
linker errors (undefined virtual table symbol in these classes, tons 
of undefined symbols mayhem, etc), which are very hard to catch 
without testing thoroughly.

I would be very happy to burn you a CD with a snapshot of my work area 
and mail it to you. It's no trouble at all for me to do this, i have 
already promised the same thing to two other guys who are also 
interested in this. I can do it this coming weekend, since it's a 
3-day weekend. :-) My only caveat: for your own sanity, please do not 
re-run 'configure'. :-) It will re-generate the Makefiles, and i had 
to hand-patch all the Makefiles one by one, because the linker flags 
are not being generated correctly, and because sometimes the 
Makefiles are generated with bogus blank lines which cause make to 
croke.

The two applications which are currently still giving me grief:
- Konqueror in web mode (i probably need to redo a full clean build 
from scratch of everything, because i've been patching khtml like 
crazy and rebuilding it locally, which usually leads to a big mess) 
-- it connects to the web site, then suddenly dies with SIGBUS -- 
this smacks of a bad build and/or inconsistent symbols.
- Noatun -- sometimes it works, sometimes it SIGSEGV because it can't 
create a Noatun::Session object (in Engine::initArts(), d->session is 
NULL after Arts::DynamicCast()). I'm still scratching my head on this 
one. :-) I have seen this problem reported on the 'net on other 
platforms, but haven't found any post as to how to fix it -- i feel 
so alone on this one :-). I really want to fix this one because when 
Noatun decides to work, it's a beauty.

Everything else works beautifully -- Konqueror in file manager mode is 
a beauty, the cd-player rocks, the sound quality is fantastic even 
with no speakers, the icons are _great_ --  they render extremely 
quickly, and the speed is very very nice!

Just let me know where to send the CD -- it's really no problem for me 
to burn it and send it to you -- actually i'm dying to try out my new 
Yamaha (24x write mode) CD-burner on my Sun :-).

I'd like to thank everyone for their patience and understanding. I 
will try my best to make it worth the wait. After i'm done with the 
32-bit version, i'm moving on to 64-bit. :-)

Once again, thank you everyone for the very kind and encouraging 
words. :-)

--Stefan

----

On Thursday 13 February 2003 12:56, Cory C. Omand wrote:
> Stefan,
>
> Are you compiling on Solaris 8 or 9?  If you are setting up on 8,
> could I get a copy of your sources to compile a similar set of
> packages for S9?  What sort of build environment are you using? 
> Have you considered a setup like GAR?
>
> Regards,
> C. Omand
>
> Stefan Teleman wrote:
> > Hi!
> >
> > Here is my status update:
> >
> > I am currently running (on my Sun Ultra 60 box) KDE 3.1 compiled
> > with Forte 7:
> > qt-3.1.1
> > arts-1.1
> > kdelibs-3.1
> > kdebase-3.1
> > kdenetwork-3.1
> > kdemultimedia-3.1
> > kdeaddons-3.1
> >
> > Since my original post, i have been fixing a lot of bugs in kio,
> > khtml/css, khtml/dom, khtml/ecma and khtml/xml, and in many other
> > places too (kdemultimedia, kdebase, kdenetwork), which made the
> > code very unstable (amongst others, missing implementations of
> > member functions declared in the header file). Unfortunately,
> > every build iteration takes me about 4 days, since i can only
> > work on this in my free time (evenings weekdays and weekends),
> > after which i test for about 3 days, and i fix whatever bugs i
> > find. So, this comes to about one build a week. I am myself
> > extremely anxious to finally post my port in Sun pkg format,
> > online, so that everyone can try it out, and hopefully enjoy it.
> > But, i don't feel comfortable making a release when i know for a
> > fact there are still bugs which need to be addressed. Not to
> > mention that, if i post a buggy, i will probably get flamed. :-)
> >
> > So, i am kindly asking everyone to bear with me for a little,
> > while i fix these bugs and i come up with a nice, clean and
> > stable release. I would like to assure everyone that i am working
> > very hard on this port and, as soon as i have a stable (and
> > relatively bug-free) build, i will post it online.
> >
> > Thanks everyone for understanding. :-)
> >
> > --Stefan
> >
> > -----
> >
> > On Wednesday 12 February 2003 04:21, Matthew Day wrote:
> >>it's been alittle while since i've heard anything, i know a few
> >> of you were trying to build 3.1 using the forte compiler for
> >> solaris. How are these attempts going? does anyone have packages
> >> yet? I'd dearly like to make them avaliable on my website for
> >> everyone.
> >>
> >>not to mention i'd like to try it myself, and have a solaris
> >>install coming up next week :-)
> >>
> >>Matt
>
> ___________________________________________________
> 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.

-- 
Stefan Teleman          'Nobody Expects the Spanish Inquisition'
steleman@nyc.rr.com                          -Monty Python