This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: More test results...
- From: Gabriel Dos Reis <gdr at codesourcery dot com>
- To: Benjamin Kosnik <bkoz at redhat dot com>
- Cc: libstdc++ at gcc dot gnu dot org, stephen dot webb at bregmasoft dot com, gcc at gcc dot gnu dot org, jason at redhat dot com
- Date: 08 Mar 2002 08:51:43 +0100
- Subject: Re: More test results...
- Organization: CodeSourcery, LLC
- References: <200203080717.g287HgF13948@fillmore.constant.com>
Benjamin Kosnik <bkoz@redhat.com> writes:
[...]
| %g++ 1.cc 2.cc 3.cc
| /tmp/ccVwNcTu.o(.bss+0x0): multiple definition of `std::numeric_limits<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >::is_integer'
| /tmp/ccrSXPkE.o(.bss+0x0): first defined here
| collect2: ld returned 1 exit status
|
| Which is a major bummer.
I'm still unclear as to why we're getting that error. Isn't the
complier and linker supposed to use the "gnu link once" technology to
eliminate redundant instantiations? As far as I can tell, those are
implicit instantiations and the compiler is required to handle them in
the appropriate way. The constructs used are daily constructs, which
means, it isn't just the library which is affected but also user code.
I think the issue has to be investigated at the compiler and linker
level.
[...]
| It looks like the best approach would be to use a base class for this
| data. Here's a patch that does that: we'll have to wait for Gaby's ok
| to check it in.
Independently of what is happening in the compiler, I think your patch
is good because it will improve the overall footprint. There is
however a minor nit: there should be corresponding definitions of the
static data members in src/limits.cc. I'm not in a position to do any
check-in, so please could do that change check in? Thanks in advance.
-- Gaby