Mailing List Archive: KDE 3.4 visibility support disabled

KDE 3.4 visibility support disabled

May 25, 2005, 9:48 AM

Post #1 of 10 (245 views)

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

Re: KDE 3.4 visibility support disabled [ In reply to ]

weeve at gentoo

May 25, 2005, 11:02 AM

Post #2 of 10 (243 views)

Permalink

-----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

Re: Re: KDE 3.4 visibility support disabled [ In reply to ]

flameeyes at gentoo

May 25, 2005, 4:57 PM

Post #3 of 10 (241 views)

Permalink

[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/

Re: [gentoo-amd64] Re: KDE 3.4 visibility support disabled [ In reply to ]

danarmak at gentoo

May 25, 2005, 9:25 PM

Post #4 of 10 (243 views)

Permalink

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

Re: Re: KDE 3.4 visibility support disabled [ In reply to ]

cryos at gentoo

May 26, 2005, 4:05 AM

Post #5 of 10 (248 views)

Permalink

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

Re: Re: Re: KDE 3.4 visibility support disabled [ In reply to ]

caleb at gentoo

May 26, 2005, 5:26 AM

Post #6 of 10 (242 views)

Permalink

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: Re: Re: KDE 3.4 visibility support disabled [ In reply to ]

deplinenoise at gmail

May 26, 2005, 9:09 AM

Post #7 of 10 (240 views)

Permalink

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: KDE 3.4 visibility support disabled [ In reply to ]

1i5t5.duncan at cox

Jun 17, 2008, 12:35 AM

Post #8 of 10 (242 views)

Permalink

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: Re: KDE 3.4 visibility support disabled [ In reply to ]

1i5t5.duncan at cox

Jun 17, 2008, 12:35 AM

Post #9 of 10 (242 views)

Permalink

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: Re: KDE 3.4 visibility support disabled [ In reply to ]

1i5t5.duncan at cox

Jun 17, 2008, 12:35 AM

Post #10 of 10 (245 views)

Permalink

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