From: don r. <don...@ya...> - 2008-04-22 14:08:50
|
I'm getting a link problem in someone else's code but I can't tell what exactly is causing it. It says it's coming from a file "ThreadLocalImpl.h" but the link error (an undefined reference to _RB_tree_node_base) is to something that's never directly called for nor included in the header file. So how do I figure out what line is causing this? Thanks. ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ |
From: Giel v. S. <me...@mo...> - 2008-04-22 14:59:16
Attachments:
signature.asc
|
don rhummy schreef: > I'm getting a link problem in someone else's code but > I can't tell what exactly is causing it. It says it's > coming from a file "ThreadLocalImpl.h" but the link > error (an undefined reference to _RB_tree_node_base) > is to something that's never directly called for nor > included in the header file. So how do I figure out > what line is causing this? You can try recompiling whatever object file has the undefined reference with debugging symbols in it. You can achieve this by passing the command line switch "-s" to gcc/g++. -- Giel |
From: JonY <10...@gm...> - 2008-04-22 15:05:50
|
Giel van Schijndel wrote: > don rhummy schreef: >> I'm getting a link problem in someone else's code but >> I can't tell what exactly is causing it. It says it's >> coming from a file "ThreadLocalImpl.h" but the link >> error (an undefined reference to _RB_tree_node_base) >> is to something that's never directly called for nor >> included in the header file. So how do I figure out >> what line is causing this? > > You can try recompiling whatever object file has the undefined reference > with debugging symbols in it. You can achieve this by passing the > command line switch "-s" to gcc/g++. > > Hi, I think you mean "-g" for debug. |
From: Giel v. S. <me...@mo...> - 2008-04-22 15:07:36
Attachments:
signature.asc
|
JonY schreef: > Giel van Schijndel wrote: >> don rhummy schreef: >>> I'm getting a link problem in someone else's code but >>> I can't tell what exactly is causing it. It says it's >>> coming from a file "ThreadLocalImpl.h" but the link >>> error (an undefined reference to _RB_tree_node_base) >>> is to something that's never directly called for nor >>> included in the header file. So how do I figure out >>> what line is causing this? >> You can try recompiling whatever object file has the undefined reference >> with debugging symbols in it. You can achieve this by passing the >> command line switch "-s" to gcc/g++. > > I think you mean "-g" for debug. Oh yes, thanks for catching this! "-s" does the exact opposite (strips debug symbols)... -- Giel |
From: don r. <don...@ya...> - 2008-04-22 17:36:50
|
Thanks. it doesn't seem to be helping though. The only real info I get is: (ThreadLocalImpl.o):ThreadLocalImpl.cxx:(.text+0x8c): What does the ".text+0x8c" mean? ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ |
From: Brian D. <br...@de...> - 2008-04-22 17:43:01
|
don rhummy wrote: > Thanks. it doesn't seem to be helping though. The only > real info I get is: > > (ThreadLocalImpl.o):ThreadLocalImpl.cxx:(.text+0x8c): > > What does the ".text+0x8c" mean? Please post the exact command you use to link and its full output, don't edit anything out. .text is the section and 0x8c is the offset within the section of the reference to the undefined variable. Brian |
From: don r. <don...@ya...> - 2008-04-22 18:18:20
|
> Please post the exact command you use to link and > its full output, don't > edit anything out. Most of these options are put in by MinGW, not me. ld.exe -Bdynamic -o Test.exe /mingw/bin/../lib/gcc/mingw32/4.2.1-sjlj/../../../crt2.o /mingw/bin/../lib/gcc/mingw32/4.2.1-sjlj/crtbegin.o -L/Development/Projects/Threads -L/mingw/bin/../lib/gcc/mingw32/4.2.1-sjlj -L/mingw/bin/../lib/gcc -L/mingw/bin/../lib/gcc/mingw32/4.2.1-sjlj/../../../../mingw32/lib -L/program files/mingw/bin/../lib/gcc/mingw32/4.2.1-sjlj/../../.. --verbose Test.o -lstdc++ -lzthread -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt -luser32 -lkernel32 -ladvapi32 -lshell32 -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt /mingw/bin/../lib/gcc/mingw32/4.2.1-sjlj/crtend.o ------------------- | OUTPUT | ------------------- using internal linker script: ================================================== /* Default linker script, for normal executables */ OUTPUT_FORMAT(pei-i386) SEARCH_DIR("/mingw//mingw32/lib"); SEARCH_DIR("/mingw//lib"); SEARCH_DIR("/usr/local/lib"); SEARCH_DIR("/lib"); SEARCH_DIR("/usr/lib"); SECTIONS { /* Make the virtual address and file offset synced if the alignment is lower than the target page size. */ . = SIZEOF_HEADERS; . = ALIGN(__section_alignment__); .text __image_base__ + ( __section_alignment__ < 0x1000 ? . : __section_alignment__ ) : { *(.init) *(.text) *(SORT(.text$*)) *(.glue_7t) *(.glue_7) ___CTOR_LIST__ = .; __CTOR_LIST__ = . ; LONG (-1);*(.ctors); *(.ctor); *(SORT(.ctors.*)); LONG (0); ___DTOR_LIST__ = .; __DTOR_LIST__ = . ; LONG (-1); *(.dtors); *(.dtor); *(SORT(.dtors.*)); LONG (0); *(.fini) /* ??? Why is .gcc_exc here? */ *(.gcc_exc) PROVIDE (etext = .); *(.gcc_except_table) } /* The Cygwin32 library uses a section to avoid copying certain data on fork. This used to be named ".data". The linker used to include this between __data_start__ and __data_end__, but that breaks building the cygwin32 dll. Instead, we name the section ".data_cygwin_nocopy" and explictly include it after __data_end__. */ .data BLOCK(__section_alignment__) : { __data_start__ = . ; *(.data) *(.data2) *(SORT(.data$*)) *(.jcr) __data_end__ = . ; *(.data_cygwin_nocopy) } .rdata BLOCK(__section_alignment__) : { *(.rdata) *(SORT(.rdata$*)) *(.eh_frame) ___RUNTIME_PSEUDO_RELOC_LIST__ = .; __RUNTIME_PSEUDO_RELOC_LIST__ = .; *(.rdata_runtime_pseudo_reloc) ___RUNTIME_PSEUDO_RELOC_LIST_END__ = .; __RUNTIME_PSEUDO_RELOC_LIST_END__ = .; } .pdata BLOCK(__section_alignment__) : { *(.pdata) } .bss BLOCK(__section_alignment__) : { __bss_start__ = . ; *(.bss) *(COMMON) __bss_end__ = . ; } .edata BLOCK(__section_alignment__) : { *(.edata) } /DISCARD/ : { *(.debug$S) *(.debug$T) *(.debug$F) *(.drectve) } .idata BLOCK(__section_alignment__) : { /* This cannot currently be handled with grouped sections. See pe.em:sort_sections. */ SORT(*)(.idata$2) SORT(*)(.idata$3) /* These zeroes mark the end of the import list. */ LONG (0); LONG (0); LONG (0); LONG (0); LONG (0); SORT(*)(.idata$4) SORT(*)(.idata$5) SORT(*)(.idata$6) SORT(*)(.idata$7) } .CRT BLOCK(__section_alignment__) : { ___crt_xc_start__ = . ; *(SORT(.CRT$XC*)) /* C initialization */ ___crt_xc_end__ = . ; ___crt_xi_start__ = . ; *(SORT(.CRT$XI*)) /* C++ initialization */ ___crt_xi_end__ = . ; ___crt_xl_start__ = . ; *(SORT(.CRT$XL*)) /* TLS callbacks */ /* ___crt_xl_end__ is defined in the TLS Directory support code */ ___crt_xp_start__ = . ; *(SORT(.CRT$XP*)) /* Pre-termination */ ___crt_xp_end__ = . ; ___crt_xt_start__ = . ; *(SORT(.CRT$XT*)) /* Termination */ ___crt_xt_end__ = . ; } .tls BLOCK(__section_alignment__) : { ___tls_start__ = . ; *(.tls) *(.tls$) *(SORT(.tls$*)) ___tls_end__ = . ; } .endjunk BLOCK(__section_alignment__) : { /* end is deprecated, don't use it */ PROVIDE (end = .); PROVIDE ( _end = .); __end__ = .; } .rsrc BLOCK(__section_alignment__) : { *(.rsrc) *(SORT(.rsrc$*)) } .reloc BLOCK(__section_alignment__) : { *(.reloc) } .stab BLOCK(__section_alignment__) (NOLOAD) : { *(.stab) } .stabstr BLOCK(__section_alignment__) (NOLOAD) : { *(.stabstr) } /* DWARF debug sections. Symbols in the DWARF debugging sections are relative to the beginning of the section. Unlike other targets that fake this by putting the section VMA at 0, the PE format will not allow it. */ /* DWARF 1.1 and DWARF 2. */ .debug_aranges BLOCK(__section_alignment__) (NOLOAD) : { *(.debug_aranges) } .debug_pubnames BLOCK(__section_alignment__) (NOLOAD) : { *(.debug_pubnames) } /* DWARF 2. */ .debug_info BLOCK(__section_alignment__) (NOLOAD) : { *(.debug_info) *(.gnu.linkonce.wi.*) } .debug_abbrev BLOCK(__section_alignment__) (NOLOAD) : { *(.debug_abbrev) } .debug_line BLOCK(__section_alignment__) (NOLOAD) : { *(.debug_line) } .debug_frame BLOCK(__section_alignment__) (NOLOAD) : { *(.debug_frame) } .debug_str BLOCK(__section_alignment__) (NOLOAD) : { *(.debug_str) } .debug_loc BLOCK(__section_alignment__) (NOLOAD) : { *(.debug_loc) } .debug_macinfo BLOCK(__section_alignment__) (NOLOAD) : { *(.debug_macinfo) } /* SGI/MIPS DWARF 2 extensions. */ .debug_weaknames BLOCK(__section_alignment__) (NOLOAD) : { *(.debug_weaknames) } .debug_funcnames BLOCK(__section_alignment__) (NOLOAD) : { *(.debug_funcnames) } .debug_typenames BLOCK(__section_alignment__) (NOLOAD) : { *(.debug_typenames) } .debug_varnames BLOCK(__section_alignment__) (NOLOAD) : { *(.debug_varnames) } /* DWARF 3. */ .debug_ranges BLOCK(__section_alignment__) (NOLOAD) : { *(.debug_ranges) } } ================================================== /Development/Projects/Threads/libzthread.a(ThreadLocalImpl.o):ThreadLocalImpl.cxx:(.text+0x8c): undefined reference to `std::_Rb_tree_rebalance_for_erase(std::_Rb_tree_node_base*, std::_Rb_tree_node_base&)' /Development/Projects/Threads/libzthread.a(ThreadLocalImpl.o):ThreadLocalImpl.cxx:(.text$_ZNSt8_Rb_treeIPKN7ZThread15ThreadLocalImplESt4pairIKS3_NS0_10CountedPtrINS1_5ValueEjEEESt10_Select1stIS9_ESt4lessIS3_ESaIS9_EE9_M_insertEPSt18_Rb_tree_node_baseSH_RKS9_[std::_Rb_tree<ZThread::ThreadLocalImpl const*, std::pair<ZThread::ThreadLocalImpl const* const, ZThread::CountedPtr<ZThread::ThreadLocalImpl::Value, unsigned int> >, std::_Select1st<std::pair<ZThread::ThreadLocalImpl const* const, ZThread::CountedPtr<ZThread::ThreadLocalImpl::Value, unsigned int> > >, std::less<ZThread::ThreadLocalImpl const*>, std::allocator<std::pair<ZThread::ThreadLocalImpl const* const, ZThread::CountedPtr<ZThread::ThreadLocalImpl::Value, unsigned int> > > >::_M_insert(std::_Rb_tree_node_base*, std::_Rb_tree_node_base*, std::pair<ZThread::ThreadLocalImpl const* const, ZThread::CountedPtr<ZThread::ThreadLocalImpl::Value, unsigned int> > const&)]+0x7a): undefined reference to `std::_Rb_tree_insert_and_rebalance(bool, std::_Rb_tree_node_base*, std::_Rb_tree_node_base*, std::_Rb_tree_node_base&)' /Development/Projects/Threads/libzthread.a(ThreadLocalImpl.o):ThreadLocalImpl.cxx:(.text$_ZNSt8_Rb_treeIPKN7ZThread15ThreadLocalImplESt4pairIKS3_NS0_10CountedPtrINS1_5ValueEjEEESt10_Select1stIS9_ESt4lessIS3_ESaIS9_EE16_M_insert_uniqueERKS9_[std::_Rb_tree<ZThread::ThreadLocalImpl const*, std::pair<ZThread::ThreadLocalImpl const* const, ZThread::CountedPtr<ZThread::ThreadLocalImpl::Value, unsigned int> >, std::_Select1st<std::pair<ZThread::ThreadLocalImpl const* const, ZThread::CountedPtr<ZThread::ThreadLocalImpl::Value, unsigned int> > >, std::less<ZThread::ThreadLocalImpl const*>, std::allocator<std::pair<ZThread::ThreadLocalImpl const* const, ZThread::CountedPtr<ZThread::ThreadLocalImpl::Value, unsigned int> > > >::_M_insert_unique(std::pair<ZThread::ThreadLocalImpl const* const, ZThread::CountedPtr<ZThread::ThreadLocalImpl::Value, unsigned int> > const&)]+0x79): undefined reference to `std::_Rb_tree_decrement(std::_Rb_tree_node_base*)' /Development/Projects/Threads/libzthread.a(ThreadLocalImpl.o):ThreadLocalImpl.cxx:(.text$_ZNSt8_Rb_treeIPKN7ZThread15ThreadLocalImplESt4pairIKS3_NS0_10CountedPtrINS1_5ValueEjEEESt10_Select1stIS9_ESt4lessIS3_ESaIS9_EE16_M_insert_uniqueESt17_Rb_tree_iteratorIS9_ERKS9_[std::_Rb_tree<ZThread::ThreadLocalImpl const*, std::pair<ZThread::ThreadLocalImpl const* const, ZThread::CountedPtr<ZThread::ThreadLocalImpl::Value, unsigned int> >,std::_Select1st<std::pair<ZThread::ThreadLocalImpl const* const, ZThread::CountedPtr<ZThread::ThreadLocalImpl::Value, unsigned int> > >, std::less<ZThread::ThreadLocalImpl const*>, std::allocator<std::pair<ZThread::ThreadLocalImpl const* const, ZThread::CountedPtr<ZThread::ThreadLocalImpl::Value, unsigned int> > > >::_M_insert_unique(std::_Rb_tree_iterator<std::pair<ZThread::ThreadLocalImpl const* const, ZThread::CountedPtr<ZThread::ThreadLocalImpl::Value, unsigned int> > >,std::pair<ZThread::ThreadLocalImpl const* const, ZThread::CountedPtr<ZThread::ThreadLocalImpl::Value, unsigned int> > const&)]+0x87): undefined reference to `std::_Rb_tree_decrement(std::_Rb_tree_node_base*)' /Development/Projects/Threads/libzthread.a(ThreadLocalImpl.o):ThreadLocalImpl.cxx:(.text$_ZNSt8_Rb_treeIPKN7ZThread15ThreadLocalImplESt4pairIKS3_NS0_10CountedPtrINS1_5ValueEjEEESt10_Select1stIS9_ESt4lessIS3_ESaIS9_EE16_M_insert_uniqueESt17_Rb_tree_iteratorIS9_ERKS9_[std::_Rb_tree<ZThread::ThreadLocalImpl const*, std::pair<ZThread::ThreadLocalImpl const* const, ZThread::CountedPtr<ZThread::ThreadLocalImpl::Value, unsigned int> >,std::_Select1st<std::pair<ZThread::ThreadLocalImpl const* const, ZThread::CountedPtr<ZThread::ThreadLocalImpl::Value, unsigned int> > >, std::less<ZThread::ThreadLocalImpl const*>, std::allocator<std::pair<ZThread::ThreadLocalImpl const* const, ZThread::CountedPtr<ZThread::ThreadLocalImpl::Value, unsigned int> > > >::_M_insert_unique(std::_Rb_tree_iterator<std::pair<ZThread::ThreadLocalImpl const* const, ZThread::CountedPtr<ZThread::ThreadLocalImpl::Value, unsigned int> > >,std::pair<ZThread::ThreadLocalImpl const* const, ZThread::CountedPtr<ZThread::ThreadLocalImpl::Value, unsigned int> > const&)]+0x114): undefined reference to `std::_Rb_tree_increment(std::_Rb_tree_node_base*)' /Development/Projects/Threads/libzthread.a(ThreadImpl.o):ThreadImpl.cxx:(.text+0x132e): undefined reference to `std::_Rb_tree_increment(std::_Rb_tree_node_base const*)' ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ |
From: Brian D. <br...@de...> - 2008-04-22 18:34:16
|
don rhummy wrote: > Most of these options are put in by MinGW, not me. > > ld.exe > -Bdynamic > -o Test.exe > /mingw/bin/../lib/gcc/mingw32/4.2.1-sjlj/../../../crt2.o > > /mingw/bin/../lib/gcc/mingw32/4.2.1-sjlj/crtbegin.o > -L/Development/Projects/Threads > -L/mingw/bin/../lib/gcc/mingw32/4.2.1-sjlj > -L/mingw/bin/../lib/gcc > -L/mingw/bin/../lib/gcc/mingw32/4.2.1-sjlj/../../../../mingw32/lib > > -L/program > files/mingw/bin/../lib/gcc/mingw32/4.2.1-sjlj/../../.. > > --verbose > Test.o > -lstdc++ > -lzthread > -lmingw32 > -lgcc > -lmoldname > -lmingwex > -lmsvcrt > -luser32 > -lkernel32 > -ladvapi32 > -lshell32 > -lmingw32 > -lgcc > -lmoldname > -lmingwex > -lmsvcrt > /mingw/bin/../lib/gcc/mingw32/4.2.1-sjlj/crtend.o Are you seriously saying this is the command you are using to link? Because linking with 'ld' is definitely the problem if so. As the other reply said, you should be always use g++ to link C++ and the command should be simply: g++ -o Test.exe Test.o -L/Development/Projects/Threads -lzthread The fact that collect2 is not being run probably explains the undefined references. Brian |
From: don r. <don...@ya...> - 2008-04-22 19:02:46
|
That's what verbose printed out. I'm using Ant to build it and I have the following: That's it. And for the compiler: <cc subsytem="console" outfile="Test.exe" outtype="executable" debug="true" name="g++" > <!-- elided the include paths but they're in the output --> <includepath value="...." /> <compilerarg value="-mthreads" /> <linker> <linkerarg value="--verbose" /> <linkerarg value="-debug" /> </linker> <libset libs="stdc++" /> <libset libs="zthread" /> </cc> --- Brian Dessent <br...@de...> wrote: > Are you seriously saying this is the command you are > using to link? > Because linking with 'ld' is definitely the problem > if so. As the other > reply said, you should be always use g++ to link C++ > and the command > should be simply: > > g++ -o Test.exe Test.o > -L/Development/Projects/Threads -lzthread > > The fact that collect2 is not being run probably > explains the undefined > references. > > Brian > ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ |
From: Tuomo L. <dj...@ik...> - 2008-04-22 19:21:19
|
don rhummy wrote: > That's what verbose printed out. I'm using Ant to > build it and I have the following: > > That's it. > > And for the compiler: > <cc > subsytem="console" ^^^^^^^^ typo? > outfile="Test.exe" > outtype="executable" > debug="true" > name="g++" > <!-- elided the include paths but they're in the > output --> > <includepath value="...." /> > > <compilerarg value="-mthreads" /> > <linker> > <linkerarg value="--verbose" /> > <linkerarg value="-debug" /> > </linker> > <libset libs="stdc++" /> > <libset libs="zthread" /> > </cc> Please don't top post. This looks like a problem with Ant and not a MinGW issue. So, maybe further inquiries on how to specify the linker should be directed to Ant people. That said, see this: http://osdir.com/ml/java.ant-contrib.devel/2005-01/msg00052.html I wouldn't know since I don't use Ant and, considering the "helpfulness" of adding yet another layer to a build process, probably won't if I can help it, but maybe simply specifying '<linker name="g++">' would work? -- Tuomo ... SS> Pitäneepi kokeilla jonkun kaverin koneella ;) ... It took me 3 install efforts to realise that the Cancel button at the end of the HL1 installer did not mean "don't install DirectX" like they implied, but "uninstall the entire thing I just spent 10 minutes installing kthx". -- on http://thedailywtf.com/Comments/When_it_0x27_s_Done.aspx?pg=2 |
From: Brian D. <br...@de...> - 2008-04-22 20:39:13
|
don rhummy wrote: > That's what verbose printed out. I'm using Ant to > build it and I have the following: What I asked for is the command that is run. We still have not gotten that. Regardles of what's in the config file, ant ends up invoking some command and that's what we need to see because it's obviously incorrect. The output of --verbose doesn't tell us the needed information. I gave you a sample of what it should look like. I don't know anything about ant, but surely there is a way to tell it to print the command that it's invoking. Until we have that information I doubt we can be of any help. Brian |
From: Earnie B. <ea...@us...> - 2008-04-23 14:59:44
|
Quoting don rhummy <don...@ya...>: > > -L/program > files/mingw/bin/../lib/gcc/mingw32/4.2.1-sjlj/../../.. > This looks suspicious. Why would it be looking in the /program files/ directory? Paths with spaces are always issues. Earnie |
From: Keith M. <kei...@us...> - 2008-04-23 23:43:42
|
On Wednesday 23 April 2008 15:59, Earnie Boyd wrote: > > -L/program > > files/mingw/bin/../lib/gcc/mingw32/4.2.1-sjlj/../../.. > > This looks suspicious. Why would it be looking in the /program > files/ directory? Paths with spaces are always issues. Perhaps because the OP, in spite of repeated advice to leave the default installation paths alone, has made a rod for his own back, by changing them anyway? Regards, Keith. |