[Bug 64103] kdevelop 3.0.0a6 fails to compile (doctreeview/doctreeviewwidget.cpp)
prefect_ at gmx.net
Sat Sep 13 16:52:05 UTC 2003
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
------- Additional Comments From prefect_ at gmx.net 2003-09-13 16:50 -------
Subject: Re: kdevelop 3.0.0a6 fails to compile (doctreeview/doctreeviewwidget.cpp)
On Saturday 13 September 2003 14:56, you wrote:
> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter.
> ------- Additional Comments From a.lucas at tu-bs.de 2003-09-13 14:56
> > There's a part of the code that tries to access an (at least in some
> > configurations) non-existing function, and you call that not a bug?
> > Considering that in another programming language, this might actually
> > be a runtime error, it's kind of a stretch to call it "not a bug".
> I use KDE 3.1.3 , QT 3.1.2 and autoconf 2.57 just like you do.
> BUT I have automake 1.7.5 and gcc 2.95.3.
> There are developers that have tested gcc 3.2.x and 3.3.x in all their
> flavors and variations so gcc version is not an issue here. But your
> outdated automake version is. Have you used the trick that I recomended
> you in the other mail to bypass the need for an uptodate automake? If
> not, please do it and if the problem presists please update automake to
> 1.6.1 at least.
Again, this doesn't seem to have anything to do with the automake version. I
checked out the latest CVS anyway, did a make -f Makefile.cvs (with
automake updated to 1.6.3), and I get exactly the same results.
What it boils down to is this: configure sets -DQT_NO_ASCII_CAST, which
masks the casting operator in qstring.h
I tracked QT_NO_ASCII_CAST down to admin/acinclude.m4.in, where it is set in
the default KDE CXXFLAGS. There doesn't seem to be any part of the
configure script that might undefine QT_NO_ASCII_CAST.
It's weird. Looks like there is no way QT_NO_ASCII_CAST could be unset in
the configure script. Sure, compilation works on your end, but if
- -DQT_NO_ASCII_CAST is set for you as well, the Qt headers must be different
somehow. I can't think of a non-weird explanation for this.
However, grep QT_NO_ASCII_CAST ChangeLog suggests that previous changes have
been made to support this condition. The rationale is probably that a
simple cast cannot express which character set you want (plain old ASCII,
[snip potential flamewar ;) - my apologies if my earlier reply sounded too
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the KDevelop-devel