This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Duplicate data objects in shared libraries


>>>>> "Mark" == Mark Mitchell <mark@codesourcery.com> 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.

> I guess my top-level opinion is that this is a good discussion, but that
> we should keep it as a discussion -- rather than an implementation -- for
> some time to come.  We should bring in other vendors too; if we do one
> thing, and HP and IBM and Sun and EDG and so forth and so on do another,
> that won't be good for people.

Certainly any changes to ld.so semantics should go through the ELF gABI
committee.  But I don't think that's as difficult as you make it sound.  :)

> I guess I think we have bigger fish to fry than making RTLD_LOCAL work
> with C++... :-)

I think that being able to write plugins in C++ is important, and a
reasonably common desire.  I know I talked to a customer several years ago
about writing Oracle plugins in C++, and it comes up regularly.  This isn't
like -Bsymbolic, where we can just say "don't do that".  If you say that in
this case, you're saying "don't use C++".  I'd prefer not to discourage
people from using C++.

Jason


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]