The KDE Project announced
KDE 3.1.3 today. It's the third maintenance release of the successful KDE 3.1.x series and
ships with many bugfixes and improved translations. KDE 3.1.3 also contains a fix for a possible HTTP authentication leak
in the HTTP referrer header. Users of KDE 3.x are advised to upgrade to KDE 3.1.3. Read the change log or directly jump to the
download links on the KDE 3.1.3 Info Page. The Konstruct build toolset was updated accordingly.
Dot Categories:
Comments
... to all the developers!
And thanks....
You guys really rock.
Thank you !
First a big,big THANK'S to the developer!
I've seen a lot of comments related to gcc3.4+ compilation issues. Is gcc3.4+ ready for production systems?
The actual snapshot of gideon had some trouble as I tried to compile it with gcc3.3.1 (prerelease from Jul. 20). I remember some trouble like
char *dst=QString (assignment (const char *) to (char *)), a double 'const' in
a xpm file (const char *name const = ...) and a lot of 'using default value for ... parameter of ( bool ... = false in the .cpp) in the Ada related stuff.
const char *name const is perfectly valid C++, and is correct.. afaik.
It is not ready until it has been released. 3.3.x is the current stable branch.
The reason for the numerous gcc 3.4 fixes is that the 3.4 branch has a new C++ parser, which is a little bit more picky about the standard.
GCC 3.4+ is not ready for use it, nonetheless we try to keep
our code compatible to as many compilers as possible.
It is not recommended to use gcc 3.4 with KDE yet as it still contains
a few miscompilations and bugs that won't make the result of compilation usable for end users.
But if you're adventurous and not afraid of tracking down bugs and fix them,
you're welcome to try :-)
I don't even recommend using GCC 3.3, as it's absolutely awful.
ICEs on xfree86 and kdebase on multiple architectures (including, but not limited to: arm, mips and mipsel), used to ICE on i386, miscompiles ?dm authentication at -O2 on every architecture (AFAICS - at least amd64, i386, ia64, powerpc and sparc), and more. If you care about your code, stay back at 3.2 until they unbreak 3.3 (haw!).
Oh yeah, and it fails to compile aspseek (a 3.2 regression), because its parser is horribly broken, and they're not planning to fix that one till 3.4. Nice one!
dm authentication? I don't see a bug like that over at gcc.gnu.org/bugzilla. If you could generate a minimal test case for it and file a bugreport there I'm sure it would be useful.
It's been filed already, and I think they've fixed it in 3.4.
With gcc 3.4, can KDE finally be compiled with precompiled headers? How much faster will gcc 3.4 w/pch compile kde compared to gcc 2.95?
This won't work until somebody adjusts the make system (and possibly the sources), because gcc can only use one precompiled header per compilation unit. So you have to create header files that contain all headers that a program uses, then precompile this header file and include it from all sources.
But what if all qt headers are pre compiled in to qt_all.h and all kde headers are compiled into kde_all.h Then all qt headers first include qt_all.h and the same with kde? Wouldn't that help?
Or what approach is one suppose to take? I really hope we don't have to change all kde program and use ifdef using gcc-3.4 then one big fat file, else all different headers?
It would work, but I am not sure whether including 1000 precompiled headers is still faster than 50 that are not precompiled :)
The intended way seems to be that each application/module/library has an all.h with all headers that it needs.
MFC in Visual C++ you just include stdafx.h and you are done.
Anyway, it will be really interesting to see what will happen when we have gcc 3.4 around. I bet there will be a big flame fest on what we should do about it. Just thing about how easy it is to use a QThatClass without including the header for people not using PCH ;=)
I've seen a few different approaches to compiled headers. The one I think makes most sense is that each program includes just the header files it requires. An all_headers.h is created which #includes all of the header files. Then to use the precompiled headers the build system adds -include precomp.h to the gcc command line. (The multiple inclusion guards in the original header files still work so they do not need to be parsed again)
This mechanism means that systems without precompiled headers don't suffer from including every single header file.
It won't be. Precompiled headers reduce compile time, because headers that are included repeatedly through a lot of sources do not have to be continuously parsed by the preprocessor.
The compiled output may be marginally different, but I doubt it will be significantly faster.
Microsoft Visual C++ 6.0 supports precompiled headers, and it makes a world of difference.
When I build Psi on Linux (gcc 3.2) and Windows (MSVC++ 6), the MSVC build process blows gcc away in terms of speed. It's probably 4 or 5 times faster. To further rub it in, I'll note that my Linux box is a P4 1.6GHz and my Windows box is a P2 400MHz.
I am very much looking forward to precompiled headers in gcc.
This has been my experience as well. I used to do MFC programming on a P3 600MHz w/ 128MB RAM. It was quite snappy. But when developing a small Qt application on Linux, My 1.33GHz w/ 768MB RAM (that's more than twice as fast) it's a serious pain in the ass.
GCC 2.95.x used to be very reasonable in compile speed, but 3.x has changed dramatically.
It's funny though that no one has commented on your message yet. I bet no one wants to believe that GCC is not all that great when it comes to compile times. Maybe it's because we shouldn't complain because it's free anyway so we should fix it ourselves.
I've been looking forward to gcc 3.4 ever since 3.2 was released. I was dissapointed to learn that it was delayed for 3.4 though, I wanted this in 3.3 :)
No, it's probably because everyone has complained about g++'s compile times so much it's
getting old on us already :-).
Everybody and their mother knows that G++ is glacially slow. Searching for "gcc slow" on google nets 112,000 Google hits. Its acknowledged even in the gcc mailing lists.
> GCC 2.95.x used to be very reasonable in compile speed, but 3.x has changed dramatically.
Awww, if you call gcc 2.95's speed reasonable, then gcc 3.x must be really, utterly, painfully slow. So I'll stay with gcc 2.95 another 4 years :-(
i've seen the difference of compiling a wxWidgets application on a PII400, with and without precompiled headers. the compile time dropped from 3 minutes to something like 40 seconds. the difference is more than obvious.
A bug that already occured in the debian packages of kde 3.1.2 found its way again into 3.1.3:
In /usr/bin/startkde line 150
LD_BIND_NOW=true kdeinit +kcminit +knotify
doesnt start kdeinit, what leads to the situation that all arts-related programs like kaboodle and noatun cant be startet. I fixed it changing to
LD_BIND_NOW=true
kdeinit +kcminit +knotify
Did this happen to anybody else?
By the way, great work guys!
The LD_BIND_NOW=true is there for a reason, the change you're suggesting is incorrect.
Can you please elaborate on what exactly crashes, and further; I'd suggest you check your libvorbis install. (Although this prolly should go into bugzilla..)
To me the original line seemed like a typo - like someone missed a line break between the variable definition and the call of kdeinit. With the litle change it works...
What didnt work was that after logging into the kde session with kdm there was no sound with every kde app like kaboodle and noatun. No startup buzz and an error message claiming that kde couldnt initalize e.g. kaboodle.
Well, as I said, the change is wrong. It effectively turns the assignment into a no-op.
FOO=bar ./app sets FOO into apps environment. Doing it on a separate line merely sets a
shell local.
Perhaps this is a dumb question, but how come there are no binary packages for Mandrake lately?
Not a dumb question at all, I was asking myself the same thing...
I think because Mandrake needs money and only provides them for a fee (club members or whatever they are called, not a mdk user myself...)
I think they will be up on Texstars RPM mirrors quite soon for users of Mandrake 9.1. The packages for 9.2 Beta 1 are already available on the offical Mandrake Cooker RPM mirrors.
Add to your /etc/apt/sources.list:
deb ftp://ftp.uni-kl.de/pub/linux/kde/stable/3.1.3/Debian woody main
What! Debian has 3.1.3 before Gentoo? Something's wrong here.
What about sid aka unstable?
Gentoo has 3.1.3, but it's still in testing. If you really can't wait a few more days, you can comment it out in /usr/portage/profiles/package.mask.
Texstar provides rpm packages of kde 3.1.3 for Mandrake. If you have not installed any sw source for Texstar, you can do it with this comand under Mandrake 9.1:
urpmi.addmedia texstar ftp://ftp.ibiblio.org/pub/Linux/distributions/contrib/texstar/mandrake/9... with hdlist.cz
If the ftp server is not reachable, then you can try this:
urpmi.addmedia texstar2 ftp://ftp.bahcesehir.edu.tr/pub/texstar/mandrake/9.1/rpms with hdlist.cz
If you are not running 9.1, you can find a mirror here: http://plf.zarb.org/~nanardon/
Import the keys:
wget -O - ftp://ftp.ibiblio.org/pub/Linux/distributions/contrib/texstar/linux/dist... | gpg --import
Finaly you may Upgrade kde:
urpmi kdebase
Or you may upgrade everything:
urpmi --auto-select
(Later, you can find new SW at texstar and update your urpmi database:
urpmi.update texstar
or
urmpi.update -a
Then you can updrade all:
urpmi --auto-select
)
you need to change this slightly to:
wget -O - ftp://ftp.ibiblio.org/pub/Linux/distributions/contrib/texstar/mandrake/g... | gpg --import
Wow. Very informative. Thanks.
Thanks for this advice, it works a treat (with the fix mentioned in the other reply). I ended up doing --auto-select, and had about 730Mb of RPMs to install (about 770 in total). I had done *no* RPM updating except for mandrake's security fixes since installing 9.1 from CD. There were a couple of very minor dependency issues:
1. saslauthd needed libcom_err.so.3 but I couldn't easily find something to satisfy it, so I uninstalled it (and postfix) :)
2. kdebase-kdm-config-file wasn't updated for 3.1.3, so I installed the 3.1.2 version instead, having to go --nodeps 'cos *that* wanted kdebase-3.1.2 ;)
All done in single-user mode, of course. Everything appears to be running just fine now.
Kudos for this release. Also, FreeBSD already merged it into the ports tree. head on over at rabarber.fuitsalad.org for precompiled packages if you want to be compiling for the next few days.
run sed -e s/if you want/if you _don't_ want/ on that sentence... Damn, I should have previewed...
I switched from 5 years of debian to SuSe 8.2 recently (Love both but don't wanna feel like a sys admin at home anymore).
How does one auto upgrade in an apt-like way to kde 3.1.3 in SuSe? I'm unclear on this matter...
I hope this fixes this small but annoying konqueror bug. :/
Thanks.
You need to be a little patient before the rpms arrive in the suse-8.2
apt repository. Just watch:
http://linux01.gwdg.de/apt4rpm/freshrpms.html
More about apt for suse at:
http://linux01.gwdg.de/apt4rpm
You can use the text or X interface of 'yast', and do Software/Online Update (or 'yast online_update')...
or just go to the KDE Control Center and choose "Yast/Software/Online Update".
Thanks for the replies.
1st of all, I checked to make sure there were suse 8.2 rpms for kde 3.1.3 before posting (though I'm still with 3.1.1 so even just getting 3.1.2 would be fine).
Those rpms are found here:
ftp://ftp.kde.org/pub/kde/stable/3.1.3/SuSE/i386/8.2
I have tried the online update too but it didn't seem to work for me. Most likely I entered the url incorrectly. I'm still not entirely sure what files yast looks for so I can add urls correctly (on my first attempt anyway). I'll go experiment a bit now and see what I can pull off.
Again, thanks.
You have to add an URL ending with "yast-source/" directory to YaST like ftp://ftp.suse.com/pub/suse/i386/supplementary/KDE/update_for_8.2/yast-s... or equivalent on mirrors - atm this only holds KDE 3.1.2 but I would expect this to be updated soon to KDE 3.1.3 once the packages are more mature/tested.
Thanks...
Now that I have it added, what do I do? Nothing seems to get me to the versions of the packages on the url (which appears to be 3.1.1 now).
Call "Install and Remove Software" or "Online Update". :-)
Neither of which seem to be doing the trick... Very strange, I'll try it some more however and see what happens.
Thanks.
I think you have to move that new ftp url up to the first place in the list...
J.A.