[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: KDE 3.0.2 on IRIX
From:       Marcus Camen <mcamen () mcamen ! de>
Date:       2002-07-11 21:46:34
[Download RAW message or body]

Am Donnerstag, 11. Juli 2002 23:14 schrieb Jesse Barnes:
> On Thu, Jul 11, 2002 at 10:16:38PM +0200, Marcus Camen wrote:
> > Thanks for the list of patches. Maybe we should found a
> > "KDE3-MipsPro-Compile-Club" as we (not suprisingly) all face the
> > same namespace problems...
> > ... and even have the same fixes for them   ;-))
>
> I think most of them are ok to go into CVS too, but I did hear a rumor
> awhile back that other compilers broke with the namespace bug
> workaround in place...

Hehe. About 1-2 month ago I initiated a litte discussion on 
kde-core-devel and kde-nonlinux rearding these namespace patches.
The short answer is that it was decided not to put these into CVS.


> > > o kcontrol/background/Makefile.am:11, moved $(LIB_KFILE) to the
> > > end of the line to fix a link problem
> > > o kcontrol/kdm/Makefile.am:8, moved $(LIB_KIO) to the end of the
> > > line to fix a link problem
> >
> > I am not an auto* guru. But maybe we can put this into CVS, no?
> > Can these changes break other platforms?
>
> I think these ones are fine to go into CVS.  The IRIX linker is just a
> little picker about link order than the GNU one.

ACK. If nobody object within the next few days I will test the Makefile
fixes on Linux (I do not expect any problems, but who knows...) and
commit them to CVS.


> > > o khelpcenter/khc_infohierarchymaker.cc, find_if, bind1st and
> > > bind2nd undefined, didn't compile khelpcenter
> >
> > I played a litte bit with the Makefile and somehow managed to
> > compile this. For me khelpcenter does work but the help ioslave
> > inside it does not. And yes, I do have the right versions of libxml2
> > and libxslt.
>
> What do those functions refer to?  What did you have to change in the
> makefiles?

I think I didn't have any problems with find_if, bind1st and bind2nd but 
only with the Makefile. I will look that up in my office tomorrow.


> > You you give as a bit information on the type (-o32, -n32, -n64) and
> > the size of the generated files? IMHO the libs and binaries (-n32)
> > are really huge campared to Linux. I do not have the numbers here
> > ATM but I can look them up if you like.
>
> Sure, here are the sizes for some of the big libraries (I compiled
> with --no-debug).
> [jbarnes@spamtin lib]$ ls -Slh
> -rwxr-xr-x   1 root     sys           15M Jul  8 15:31 libkio.so.5.0
> -rwxr-xr-x   1 root     sys           10M Jul  8 16:06 libkhtml.so.5.0
> -rwxr-xr-x   1 root     sys          5.8M Jul  8 15:28 libkdeui.so.5.0
> -rwxr-xr-x   1 root     sys          5.2M Jul  8 17:40 kicker.so
> -rwxr-xr-x   1 root     sys          4.0M Jul  8 15:27
> libkdecore.so.5.0
>
> Seem pretty big to me too.

Just a wild guess: Maybe the linker links more symbols into the libraries 
than necessary?


>  I'll bet that the optimization level has a
> big effect on binary size, but I'm not gonna recompile with -O1 -O2
> -O3 just to find out :) (well, unless I can get some time on an O3k
> with >16p).

I build with -O2. I don't see much differece in filesizes compared to
your numbers.

To build KDE3 I use a 32 processor, 16 GB RAM Origin. But I am also root
on an O3k (sorry, I do not recall the number of processors right know --
something between 10 and 100).
:-))))))

Multiple processors do not help that much with KDE but I really couldn't
believe how fast QT compiled using all 32 CPUs.  :-))


> > Do have any idea of new MipsPro versions without these namespace
> > bug?
>
> I know they're working on the new version now, but I don't know what
> the exact release date will be.  Maybe sometime in the Fall?
>
> > Do you intend to try to compile an alpha of KDE3.1?
>
> Sure, if I get time I'll give it a try.

Hehe. And again we share the same problem...

-- 
Marcus Camen

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]