This is the mail archive of the
mailing list for the GCC project.
Re: Duplicate data objects in shared libraries
- From: Mark Mitchell <mark at codesourcery dot com>
- To: Jason Merrill <jason at redhat dot com>
- Cc: "Martin v. Loewis" <martin at v dot loewis dot de>, David Abrahams <david dot abrahams at rcn dot com>, "H . J . Lu" <hjl at lucon dot org>, "drepper at redhat dot com" <drepper at redhat dot com>, "Ralf W. Grosse-Kunstleve" <rwgk at cci dot lbl dot gov>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Mon, 20 May 2002 12:14:38 -0700
- Subject: Re: Duplicate data objects in shared libraries
- References: <firstname.lastname@example.org><email@example.com>
--On Monday, May 20, 2002 08:06:56 PM +0100 Jason Merrill
>>>>>> "Mark" == Mark Mitchell <firstname.lastname@example.org> writes:
>>> A good point, though we could handle this by decorating the RTTI name
>>> for S with the unnamed namespace qualifier. I suppose this sort of
>>> thing is what leads people to want to remove internal linkage entirely.
>> We're clearly in the land of corner cases, but changing the RTTI name for
>> S would be an incompatible ABI change.
> I don't think it would be incompatible; S is file-local, so its
> compatibility with things from other files is either uninteresting or
> actually undesirable.
Hmm. I think that the ABI specifies the name -- even for the local class
in the method with static linkage -- and therefore I can write
ABI-conforming code that does:
if (strcmp (typeid (S).name(), "<mangled name here>") != 0)
It would be reasonable to have an ABI that says basically nothing about
objects with internal linkage, but I don't think ours does.
> I think that being able to write plugins in C++ is important, and a
I guess I just don't think that using RTLD_LOCAL is the only reasonable
way to do it.
But, if there's a good solution here, we should definitely do it.
Mark Mitchell email@example.com
CodeSourcery, LLC http://www.codesourcery.com