This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: V3 static data in classes vs AIX
- To: dje at watson dot ibm dot com
- Subject: Re: V3 static data in classes vs AIX
- From: Mark Mitchell <mark at codesourcery dot com>
- Date: Mon, 04 Jun 2001 13:24:58 -0700
- Cc: gdr at codesourcery dot com, bkoz at redhat dot com, libstdc++ at gcc dot gnu dot org
- Organization: CodeSourcery, LLC
- References: <mark@codesourcery.com><200106042013.QAA31064@makai.watson.ibm.com>
First, did you try the change I suggested? We might as well be
testing that while we talk.
Your latest example does have a definition, not a reference:
template <typename T> int S<T>::i;
Yes, but probably your example does too. Or else it has a `const'
static data member?
This latest commentary really doesn't make sense to me. Why is
the compiler wrong and the library header right? It seems that you
Why do you think there is a problem with the library header? In the
latest test case you had, you were still including the headers; you
didn't show any code from the header itself?
These are template data members, so the headers *must* contain
definitions; otherwise, the compiler cannot figure out how to
instantiate them for arbitrary types.
trying to replicate incorrect semantics that are being generated on
systems with WEAK symbol support.
Hmm? The idea is that there is no obvious unique place to put these
definitions, so you put them everywhere you need them, and then let
the linker merge all the definitions. That's one way of achieving the
correct C++ semantics; template prelinkers and template repositories
are the other well-known technique.
We don't have a template prelinker or a template repository, so we are
stuck with the define everywhere plan. But that doesn't work on AIX
due to lack of weak symbols. (The whole point of weak (or, more
properly, COMDAT) symbols is that multiple definitions are merged.
So, we have to fall back to the define *nowhere* plan, and use
explicit instantiation on AIX.
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com