www.digitalmars.com Home | Search | C & C++ | D | DMDScript | News Groups | index | prev | next
Archives

D Programming
D
D.gnu
digitalmars.D
digitalmars.D.bugs
digitalmars.D.dtl
digitalmars.D.dwt
digitalmars.D.announce
digitalmars.D.learn
digitalmars.D.debugger

C/C++ Programming
c++
c++.announce
c++.atl
c++.beta
c++.chat
c++.command-line
c++.dos
c++.dos.16-bits
c++.dos.32-bits
c++.idde
c++.mfc
c++.rtl
c++.stl
c++.stl.hp
c++.stl.port
c++.stl.sgi
c++.stlsoft
c++.windows
c++.windows.16-bits
c++.windows.32-bits
c++.wxwindows

digitalmars.empire
digitalmars.DMDScript

c++ - Linker error - not enough characters in symbol resolution??

↑ ↓ ← "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
I get the following when trying to link one of the STLSoft unit-test 
programs.

I'm guessing that there aren't enough symbols used to discriminate 
between records, but it's all conjecture.

(Am using DMC++ 8.44 b3, btw; also happens with 8.43)

Cheers

Matthew


link -DELEXECUTABLE -NOLOGO 
.\stlsoft.unittest.obj+.\stlsoft.unittest.0.obj+.\stlsoft.unittest.1.obj+.\stlsoft.unittest.2.obj+.\stlsoft.unittest.3.obj+.\stlsoft
.unittest.4.obj+.\stlsoft.unittest.5.obj+.\stlsoft.unittest.6.obj+.\stlsoft.unittest.7.obj+.\stlsoft.unittest.8.obj+.\stlsoft.unittest.9.obj+.\stlsoft.unittest.
10.obj+.\stlsoft.unittest.11.obj,"..\..\bin\stlsoft.unittest.dm.stlsof
.exe",,kernel32.lib 
..\..\lib\stlsoft.unittest.dm.lib kernel32.lib
OPTLINK (R) for Win32  Release 7.50B1
Copyright (C) Digital Mars 1989 - 2001  All Rights Reserved

.\stlsoft.unittest.1.obj(stlsoft.unittest.1)  Offset 015DCH Record 
Type 0091
 Error 1: Previous Definition Different : 
?s_allocator ?1??get_allocator ?$auto_buffer stlsoft HV?$new_allocator stlsoft H 1 $0BA  stlsoft  SAAAV?$new_allocator
 stlsoft H 3 XZ23 4V43 A
.\stlsoft.unittest.3.obj(stlsoft.unittest.3)  Offset 01E50H Record 
Type 0091
 Error 1: Previous Definition Different : 
?s_allocator ?1??get_allocator ?$auto_buffer stlsoft HV?$new_allocator stlsoft H 1 $0BA  stlsoft  SAAAV?$new_allocator
 stlsoft H 3 XZ23 4V43 A
.\stlsoft.unittest.4.obj(stlsoft.unittest.4)  Offset 01B08H Record 
Type 0091
 Error 1: Previous Definition Different : 
?s_allocator ?1??get_allocator ?$auto_buffer stlsoft HV?$new_allocator stlsoft H 1 $0BA  stlsoft  SAAAV?$new_allocator
 stlsoft H 3 XZ23 4V43 A
.\stlsoft.unittest.5.obj(stlsoft.unittest.5)  Offset 018D5H Record 
Type 0091
 Error 1: Previous Definition Different : 
?s_allocator ?1??get_allocator ?$auto_buffer stlsoft HV?$new_allocator stlsoft H 1 $0BA  stlsoft  SAAAV?$new_allocator
 stlsoft H 3 XZ23 4V43 A
.\stlsoft.unittest.6.obj(stlsoft.unittest.6)  Offset 019CAH Record 
Type 0091
 Error 1: Previous Definition Different : 
?s_allocator ?1??get_allocator ?$auto_buffer stlsoft HV?$new_allocator stlsoft H 1 $0BA  stlsoft  SAAAV?$new_allocator
 stlsoft H 3 XZ23 4V43 A
.\stlsoft.unittest.7.obj(stlsoft.unittest.7)  Offset 01BCDH Record 
Type 0091
 Error 1: Previous Definition Different : 
?s_allocator ?1??get_allocator ?$auto_buffer stlsoft HV?$new_allocator stlsoft H 1 $0BA  stlsoft  SAAAV?$new_allocator
 stlsoft H 3 XZ23 4V43 A
.\stlsoft.unittest.8.obj(stlsoft.unittest.8)  Offset 01A20H Record 
Type 0091
 Error 1: Previous Definition Different : 
?s_allocator ?1??get_allocator ?$auto_buffer stlsoft HV?$new_allocator stlsoft H 1 $0BA  stlsoft  SAAAV?$new_allocator
 stlsoft H 3 XZ23 4V43 A
.\stlsoft.unittest.8.obj(stlsoft.unittest.8)  Offset 01F19H Record 
Type 0091
 Error 1: Previous Definition Different : 
?s_allocator ?1??get_allocator ?$auto_buffer stlsoft HV?$malloc_alloca
or stlsoft H 1 $0EA 
(unsigned char ?1??get_allo
cator::H::stlsoft::HV?$malloc_allocator::lsoft::auto_buffer<>::?1??get_allocator::s_allocator)
.\stlsoft.unittest.9.obj(stlsoft.unittest.9)  Offset 024B7H Record 
Type 0091
 Error 1: Previous Definition Different : 
?s_allocator ?1??get_allocator ?$auto_buffer stlsoft HV?$new_allocator stlsoft H 1 $0BA  stlsoft  SAAAV?$new_allocator
 stlsoft H 3 XZ23 4V43 A 
Jul 15 2005
↑ ↓ "Walter" <newshound digitalmars.com> writes:
"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
news:dba5sv$ttq$1 digitaldaemon.com...
 I get the following when trying to link one of the STLSoft unit-test
 programs.

 I'm guessing that there aren't enough symbols used to discriminate
 between records, but it's all conjecture.

All it means is that the same symbol is defined in multiple .obj files.
Jul 16 2005
↑ ↓ "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Walter" <newshound digitalmars.com> wrote in message 
news:dbbefm$1te2$2 digitaldaemon.com...
 "Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
 news:dba5sv$ttq$1 digitaldaemon.com...
 I get the following when trying to link one of the STLSoft 
 unit-test
 programs.

 I'm guessing that there aren't enough symbols used to 
 discriminate
 between records, but it's all conjecture.

All it means is that the same symbol is defined in multiple .obj files.

Well, duh! Of course that's what it means. That's obviously not where the problem lies. What I'm saying is that it's wrong, or to be more precise: either the linker is correctly detecting that the compiler is making multiple instances of something for which there should only be one, or that the linker is not correctly coallescing multiple definitions into one, as dictated by the language inlining rules. And the confidence with which I say this, and made the original post, over and above the fact that I'm doing something C++-sensible is that about 16 other compilers compile and link an executable from the same sources successfully. Anyway, I've found a workaround now. Just one more #ifdef STLSOFT_COMPILER_IS_DMC ... ;-(
Jul 16 2005
↑ ↓ → "Walter" <newshound digitalmars.com> writes:
"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
news:dbcb09$2gur$1 digitaldaemon.com...
 What I'm saying is that it's wrong, or to be more precise: either
 the linker is correctly detecting that the compiler is making
 multiple instances of something for which there should only be one,
 or that the linker is not correctly coallescing multiple definitions
 into one, as dictated by the language inlining rules. And the
 confidence with which I say this, and made the original post, over
 and above the fact that I'm doing something C++-sensible is that
 about 16 other compilers compile and link an executable from the
 same sources successfully.

 Anyway, I've found a workaround now. Just one more #ifdef
 STLSOFT_COMPILER_IS_DMC ... ;-(

If you can isolate it down to a small test case, I can take a whack at it.
Jul 20 2005