From: Waldo Bastian <bastian@kde.org>
To: Joe Buck <jbuck@synopsys.com>,
Franz Sirl <Franz.Sirl-kernel@lauterbach.com>
Cc: kde-core-devel@mail.kde.org, gcc@gcc.gnu.org
Subject: Re: KDE hackers, please read (was [nathan@codesourcery.com: Re: GCC 3.0.3: Bugs to Fix]) (fwd)
Date: Sun, 09 Dec 2001 23:58:00 -0000 [thread overview]
Message-ID: <200112100729.fBA7TSl18050@linux.local> (raw)
In-Reply-To: <200112042250.OAA02613@atrus.synopsys.com>
On Tuesday 04 December 2001 02:50 pm, Joe Buck wrote:
> > The alternative, banning RTTI from KDE, isn't very attractive either.
>
> What if you only use RTLD_GLOBAL for those libraries that define base
> classes that you'll want to do RTTI with? Or use it everywhere except
> with libraries that you know are problematic and sloppy with name spaces,
> like the flash plugin and OpenGL.
The problem that we had was with things like templates. If two plugins use the
same template, they will get the same symbol-names. When the symbols are
loaded in the global namespace, it can happen that plugin A resolves against
the symbols of plugin B. When you now unload plugin B you will get a crash
the next time you access plugin A.
(Unloading plugins is a risky business anyway, because with 2.9x the process
will crash on exit when there were static objects declared within
function-scope in the plugin.)
To what _extent_ does linking without RTLD_GLOBAL break RTTI? Looking at
PR3993 breakage there seems to happen because the module that does the
dlopen'ing doesn't strongly define class B (how do you call that, "class B
isn't being emitted"?) That situation could be prevented most of the time I
think. (I believe such classes also have a negative impact on prelinking)
Wouldn't then the only remaining problem be classes that are defined in both
plugin A and plugin B (e.g. template) but aren't defined in the module that
loads them? RTTI-wise such classes would be considered distinct then if I
understand correctly?
Franz: You described PR3993 as "another KDE2 blocking bug", where does this
behaviour break stuff in KDE?
Cheers,
Waldo
next prev parent reply other threads:[~2001-12-10 7:35 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <Pine.LNX.4.42.0112041339390.30216-110000@bochum.stuttgart.redhat.com>
2001-12-04 13:21 ` Waldo Bastian
2001-12-04 13:29 ` shaheed
2001-12-04 14:51 ` Joe Buck
2001-12-04 16:37 ` Dirk Mueller
2001-12-05 12:16 ` Mark Mitchell
2001-12-09 23:58 ` Waldo Bastian [this message]
2001-12-10 0:52 ` Simon Hausmann
2001-12-10 2:45 ` Lubos Lunak
2001-12-10 9:55 ` Mark Mitchell
2001-12-10 11:16 ` KDE hackers, please read (was [nathan@codesourcery.com: Re: GCC Joe Buck
2001-12-10 11:39 ` Mark Mitchell
2001-12-10 11:47 ` Joe Buck
2001-12-11 13:00 ` KDE hackers, please read (was [nathan@codesourcery.com: Re: GCC 3.0.3: Bugs to Fix]) (fwd) Alexandre Oliva
2001-12-11 9:28 ` Mark Mitchell
2001-12-10 1:33 ` Richard Henderson
2001-12-10 2:41 ` Andreas Schwab
2001-12-10 2:07 ` Nathan Sidwell
2001-12-10 3:01 ` Jakub Jelinek
2001-12-05 1:23 ` Nathan Sidwell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200112100729.fBA7TSl18050@linux.local \
--to=bastian@kde.org \
--cc=Franz.Sirl-kernel@lauterbach.com \
--cc=gcc@gcc.gnu.org \
--cc=jbuck@synopsys.com \
--cc=kde-core-devel@mail.kde.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).