Conference turris::c_plus_plus

3596.0. "Multiply defined, typedef of map templates?" by KERNEL::PULLEY (Come! while living waters flow) Mon Jun 02 1997 13:07

Hi,

My customer has a problem on Digital UNIX v4.0b, C++ v5.5-004, Ld v3.11.

There's two examples below, one gives two multiply defined symbols.
The other, with only a different type name, doesn't.

The errors are something like this--some of the names got choped off when
I copied it in this error output, but I think you'll get the picture.
csh> cxx -define_templates mm.cxx
ld:
mm.o:
insert__1075rb_tree__T55basic_string__Tc22string_char_traits__Tc13allocator__Tc282pair__TC55basic_string__Tc22string_char_trai
ts__Tc13allocator__Tc214map__T55basic_string__Tc22string_char_traits__Tc13allocator__Tc1S64less__T55basic_string__Tc22string_char_tr
aits__Tc13allocator__Tc81allocator__T67pair__TC55basic_string__Tc22string_char_traits__Tc13allocator__Tc1S354select1st__T282pair__TC
55basic_string__Tc22string_char_traits__Tc13allocator__Tc214map__T55basic_string__Tc22string_char_traits__Tc13allocator__Tc1S64less_
_T55basic_string__Tc22string_char_traits__Tc13allocator__Tc81allocator__T67pair__TC55basic_string__Tc22string_char_traits__Tc13alloc
ator__Tc1S55basic_string__Tc22string_char_traits__Tc13allocator__Tc64less__T55basic_string__Tc22string_char_traits__Tc13allocator__T
c297allocator__T282pair__TC55basic_string__Tc22string_char_traits__Tc13allocator__Tc214map__T55basic_string__Tc22string_char_traits_
_Tc13allocator__Tc1S64less__T55basic_string__Tc22string_char_traits__Tc13allocator__Tc81allocator0000000:
multiply defined
mm.o:
erase__1075rb_tree__T55basic_string__Tc22string_char_traits__Tc13allocator__Tc282pair__TC55basic_string__Tc22string_char_trait
s__Tc13allocator__Tc214map__T55basic_string__Tc22string_char_traits__Tc13allocator__Tc1S64less__T55basic_string__Tc22string_char_tra
its__Tc13allocator__Tc81allocator__T67pair__TC55basic_string__Tc22string_char_traits__Tc13allocator__Tc1S354select1st__T282pair__TC5
5basic_string__Tc22string_char_traits__Tc13allocator__Tc214map__T55basic_string__Tc22string_char_traits__Tc13allocator__Tc1S64less__
T55basic_string__Tc22string_char_traits__Tc13allocator__Tc81allocator__T67pair__TC55basic_string__Tc22string_char_traits__Tc13alloca
tor__Tc1S55basic_string__Tc22string_char_traits__Tc13allocator__Tc64less__T55basic_string__Tc22string_char_traits__Tc13allocator__Tc
297allocator__T282pair__TC55basic_string__Tc22string_char_traits__Tc13allocator__Tc214map__T55basic_string__Tc22string_char_traits__
Tc13allocator__Tc1S64less__T55basic_string__Tc22string_char_traits__Tc13allocator__Tc81allocator_0sdi6d8:
multiply defined

Can anyone tell me if it's still a problem in v5.6, or if there's a workaround?

Thanks,
Steve.

None working example:-
--------------------------------------------------------------------------------
#include <string>
#include <map>
typedef struct { string s; } S;
typedef map <string,S> M1;
typedef map <string,M1> M2;
--------------------------------------------------------------------------------

Working example:-
--------------------------------------------------------------------------------
#include <string>
#include <map>
typedef struct { string s; } Ss;
typedef map <string,Ss> M1;
typedef map <string,M1> M2;
--------------------------------------------------------------------------------

I can't seem to reproduce the problem the customer is describing. 
Did they remove their cxx_repository before they ran the example?

This is what I tried:

cosf.zko.dec.com> cat mm.cxx
#include <string>
#include <map>
typedef struct { string s; } S;
typedef map <string,S> M1;
typedef map <string,M1> M2;

main() { return 0; }
cosf.zko.dec.com> $CEXE/deccxx_driver -V -define_templates mm.cxx
/usr/proj/decc2/v55_cxx-016/cxxalphaosf/bl32/exe/deccxx_driver  (cxx)
DEC C++ V5.5-004 on Digital UNIX (Alpha)
/usr/ucb/ld version 3.11
cosf.zko.dec.com> $CEXE/deccxx_driver -define_templates mm.cxx
cosf.zko.dec.com> ls
a.out     mm.cxx    response
cosf.zko.dec.com> a.out
cosf.zko.dec.com>

The problem may be related to another problem
which has not been fixed in V5.6 -- this
is in the digital unix known problems list
in the V5.6 release notes:

>When creating very complicated instantiations (for example, 
>a map of a map of string), you may get a link error
>when using automatic instantiation (the name of the undefined 
>symbol will be longer than 1022 chars). 
>
>To workaround this, you can use manual instantiation or 
>local instantiation (see Section 1.11). 

Of course, if the problem which was described in .0 exists, 
this wouldn't be a very good workaround!

I reproduced your problem with an older set of header files.
Please check your header files.  The newer string and map has the following
text in the begining of its file:

string:

/***************************************************************************
 *
 * string - Declarations for the Standard Library string classes
 *
 * $Id: string,v 1.208 1996/11/05 18:54:08 smithey Exp $
 *
 ************************************************************************

map:

...
/***************************************************************************
 *
 * map - declarations for the Standard Library map class
 *
 * $Id: map,v 1.47 1996/09/11 23:03:17 smithey Exp $
 *
 ***************************************************************************

I was able to reproduce it using the installed compiler
on Shi-Jung's machine (thanks, Shi-Jung) and then I tried using
a v5.6 compiler and the problem went away. So I think it
is fixed in v5.6.

Sorry for the confusion...

    Well I took a look at the string & map STL files.
    (Haven't checked the customer's yet as I've got the problem here also,
    and he's on v3.2g of UNIX, I'm on v4.0b).
    The map & string files didn't look like those in .2.
    In fact the map says it's Hewlett-Packard.
    Where can I get hold of the newer STLs--I'd like to try them
    with the v5.5 compiler to see if that works, as my customer may not be
    able to use the field test 5.6 easily.
    
    Thanks again,
    Steve.
    

The header files mentioned in .2 are for V5.6 and
they will not work with a V5.5 compiler.

You have the correct compiler and header files,
it looks like the customer has hit a V5.5 compiler bug in
V5.5 that will be fixed in V5.6.