[gentoo-dev] KDE 3.4 visibility support disabled

[gentoo-dev] KDE 3.4 visibility support disabled

[Marcus D. Hanwell]

[-- Attachment #1: Type: text/plain, Size: 1487 bytes --]

Dear All,

I have just committed a fix to kde.eclass and kde-meta.eclass that disables 
visibility support in KDE 3.4 (thanks to FlameEyes for the patches). This was 
a new feature in KDE 3.4 which has caused at least one obvious bug, and 
possibly others that are less obvious[1].

Anyone still using GCC 3.3 will not be affected by this bug at all as only GCC 
3.4 and GCC 4.0 have visibility support. I have been working on a mixed 
system (some of KDE compiled with, and some without visibility support) and 
not encountered any issues.

An easy way to see if you are affected by this bug is to open kasteroids and 
press any key to start a game. If it segfaults then you are affected by this 
bug, recompiling kde-base/kdelibs and kde-base/kasteroids (or 
kde-base/kdegames) with the patched eclasses will cure this problem.

KDE 3.4.1 will be released soon, and so will prompt most people to recompile 
for all the bug fixes/enhancements it has. I would recommend most people just 
let KDE components recompile as updates are committed. Please find me on IRC, 
or post comments to the Gentoo bug[2] if you have problems after using the 
updated eclass.

[1] http://bugs.kde.org/show_bug.cgi?id=101542
[2] http://bugs.gentoo.org/show_bug.cgi?id=86898

P.S. PPC, PPC64 and Sparc developers may also want to post this to 
architecture specific lists too.

Thanks,

Marcus
-- 
Gentoo Linux Developer
Scientific Applications | AMD64 | KDE | net-proxy

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] KDE 3.4 visibility support disabled

[Jason Wever]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 25 May 2005, Marcus D. Hanwell wrote:

> P.S. PPC, PPC64 and Sparc developers may also want to post this to
> architecture specific lists too.

Regular SPARC users are fine as we're still using GCC 3.3.x in the main 
profiles.  Thanks for the update! :)

Cheers,
- -- 
Jason Wever
Gentoo/Sparc Co-Team Lead
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFClL2+dKvgdVioq28RAp+lAKC3y4nauFnN5Myamn8SCrv2db30kACgo5cN
MkTIG1i6IsxoMXzMbvUKbIk=
=VdEv
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: KDE 3.4 visibility support disabled

[Duncan]

Marcus D. Hanwell posted <200505251748.27667.cryos@gentoo.org>, excerpted
below,  on Wed, 25 May 2005 17:48:20 +0100:

> I have just committed a fix to kde.eclass and kde-meta.eclass that
> disables visibility support in KDE 3.4 (thanks to FlameEyes for the
> patches). This was a new feature in KDE 3.4 which has caused at least one
> obvious bug, and possibly others that are less obvious[1].

[note the cross-posting]

That isn't going to kill it for gcc-4.0.1-snapshots, right, only gcc-3.4?
I'll be rather unhappy if the speed increases I've been attributing to
that visibility support under gcc4, disappear! =8^(

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: KDE 3.4 visibility support disabled

[Diego 'Flameeyes' Pettenò]

[-- Attachment #1: Type: text/plain, Size: 1037 bytes --]

[just to make sure that everybody will hear that]

On Thursday 26 May 2005 01:37, Duncan wrote:
> That isn't going to kill it for gcc-4.0.1-snapshots, right, only gcc-3.4?
> I'll be rather unhappy if the speed increases I've been attributing to
> that visibility support under gcc4, disappear! =8^(
It will be *completely* disabled.

-fvisibility=hidden *must not* be used if the project isn't supposed to use 
only its own code without linking to other libraries, as that kills the RTTI 
stuff.

It's not a fault in GCC, it's a fault in the way -fvisibility=hidden was used 
by KDE.
KDE 3.5 and 4 will have the right visibility support enabled just for KDE 
stuff instead of messing around with QT and other libraries which doesn't use 
that consistently.

Please note that every try to use -fvisibility=hidden in CFLAGS will result in 
*great* problems which won't be supported at all.

-- 
Diego "Flameeyes" Pettenò
Gentoo Developer (Gentoo/FreeBSD, Video, Gentoo/AMD64)

http://dev.gentoo.org/~flameeyes/


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: [gentoo-amd64] Re: KDE 3.4 visibility support disabled

[Dan Armak]

[-- Attachment #1: Type: text/plain, Size: 1170 bytes --]

On Thursday 26 May 2005 02:37, Duncan wrote:
> Marcus D. Hanwell posted <200505251748.27667.cryos@gentoo.org>, excerpted
>
> below,  on Wed, 25 May 2005 17:48:20 +0100:
> > I have just committed a fix to kde.eclass and kde-meta.eclass that
> > disables visibility support in KDE 3.4 (thanks to FlameEyes for the
> > patches). This was a new feature in KDE 3.4 which has caused at least one
> > obvious bug, and possibly others that are less obvious[1].
>
> [note the cross-posting]
>
> That isn't going to kill it for gcc-4.0.1-snapshots, right, only gcc-3.4?
> I'll be rather unhappy if the speed increases I've been attributing to
> that visibility support under gcc4, disappear! =8^(

That's going to kill it everywhere, gcc4 included. The way KDE uses hidden 
visibility is itself broken - not gcc. Until that's fixed, we're disabling 
visibility support in kde. (There was a separate bug in gcc itself which got 
fixed, which may have confused some people...)

-- 
Dan Armak
Gentoo Linux developer (KDE)
Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key
Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD  0069 508D 9143 8D5F 8951

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: Re: KDE 3.4 visibility support disabled

[Duncan]

Dan Armak posted <200505260725.29929.danarmak@gentoo.org>, excerpted
below,  on Thu, 26 May 2005 07:25:21 +0300:

> That's going to kill it everywhere, gcc4 included. The way KDE uses hidden 
> visibility is itself broken - not gcc. Until that's fixed, we're disabling 
> visibility support in kde. (There was a separate bug in gcc itself which got 
> fixed, which may have confused some people...)

Ahh... yes.  Distinctive separate bug makes more sense, now.  I had only
known about the gcc bug.

So the KDE problem... Is that what's causing all those virtual function
but destructor isn't virtual type warnings whenever I compile a KDE ebuild
with gcc4?

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: KDE 3.4 visibility support disabled

[Caleb Tennis]

On Thursday 26 May 2005 02:30 am, Duncan wrote:
> So the KDE problem... Is that what's causing all those virtual function
> but destructor isn't virtual type warnings whenever I compile a KDE ebuild
> with gcc4?

No, that's just shoddy C++ coding that also needs to be fixed.

Caleb
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: KDE 3.4 visibility support disabled

[Andreas Fredriksson]

On 5/26/05, Caleb Tennis <caleb@gentoo.org> wrote:

> On Thursday 26 May 2005 02:30 am, Duncan wrote:
> > So the KDE problem... Is that what's causing all those virtual function
> > but destructor isn't virtual type warnings whenever I compile a KDE ebuild
> > with gcc4?
> 
> No, that's just shoddy C++ coding that also needs to be fixed.

Sorry to cut in like this, but I get tired of comments like this.
While this specific case might very well represent "shoddy" coding,
there are perfectly good reasons to have non-virtual destructors in
classes designed to be base classes.

One common case is when COM-style reference counting is used. In such
a scenario leaf classes always implement a release() member function
which deletes 'this' when the reference count goes to zero. With this
configuration there is no need for a virtual destructor since
destructor chaining always happens from a leaf class.

I hope one day GCC's warning for this will be smart enough to at least
not complain about non-public non-virtual destructors in classes that
otherwise contain virtual member functions. Then the warning will be
useful and perhaps indicate "shoddy C++ coding". :-)

// Andreas

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: KDE 3.4 visibility support disabled

[Marcus D. Hanwell]

[-- Attachment #1: Type: text/plain, Size: 1208 bytes --]

On Thursday 26 May 2005 00:37, Duncan wrote:
> Marcus D. Hanwell posted <200505251748.27667.cryos@gentoo.org>, excerpted
>
> below,  on Wed, 25 May 2005 17:48:20 +0100:
> > I have just committed a fix to kde.eclass and kde-meta.eclass that
> > disables visibility support in KDE 3.4 (thanks to FlameEyes for the
> > patches). This was a new feature in KDE 3.4 which has caused at least one
> > obvious bug, and possibly others that are less obvious[1].
>
> [note the cross-posting]
>
> That isn't going to kill it for gcc-4.0.1-snapshots, right, only gcc-3.4?
> I'll be rather unhappy if the speed increases I've been attributing to
> that visibility support under gcc4, disappear! =8^(
>
It seems that this has already been answered, but the KDE bug contains some 
more of the detail. It looks like KDE 3.5/4 is the target for getting proper 
visibility support. We haven't taken this decision lightly, and I believe it 
is the best option we have for a stable desktop.

KDE/QT 4 should have much improved visibility support, and I will be testing 
them once it is workable and I have a little spare time
-- 
Gentoo Linux Developer
Scientific Applications | AMD64 | KDE | net-proxy

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: Re: KDE 3.4 visibility support disabled

[Duncan]

Marcus D. Hanwell posted <200505261205.40902.cryos@gentoo.org>, excerpted
below,  on Thu, 26 May 2005 12:05:36 +0100:

> It seems that this has already been answered, but the KDE bug contains
> some more of the detail. It looks like KDE 3.5/4 is the target for getting
> proper visibility support. We haven't taken this decision lightly, and I
> believe it is the best option we have for a stable desktop.
> 
> KDE/QT 4 should have much improved visibility support, and I will be
> testing them once it is workable and I have a little spare time

Yes, I'm pretty much resigned to having to wait until kde4 for proper gcc4
support, but am /really/ looking forward to that!

BTW, it's a bit off topic for this thread, but if there's someplace you
could point me to with updated info on what's happening to arts and/or
what's going to be replacing it in kde4, I know quite a number of folks
that are interested.  It seems I knew more than most when the topic came
up in at least two groups (the amd64 list, and the local *ix group here at
Cox), but my info is now severely outdated, since most of it is from last
year's aKademy coverage and the like, when the only thing really settled
was that 3.4 would continue to use ARTS and they would look at a
replacement for 4.0.  Now that 4.0 is getting closer, one would hope the
kde4 sound question has been resolved rather more concretely than that,
and as I said, I know a lot of folks (certainly myself included) that will
be interested in learning more about whatever has been concluded.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list