Bug 43882

Summary: 4.5.0 produces missing symbols (std::_List_node_base::_M_hook ...)
Product: gcc Reporter: Yuri <yuri>
Component: c++Assignee: Not yet assigned to anyone <unassigned>
Status: RESOLVED INVALID    
Severity: major CC: gcc-bugs
Priority: P3    
Version: unknown   
Target Milestone: ---   
Host: Target:
Build: Known to work:
Known to fail: Last reconfirmed:

Description Yuri 2010-04-25 00:22:57 UTC 
I have a c++ project with a lots of STL.
It compiles fine with gcc 4.3.1 and 4.4.3, but with the new 4.5.0 I get those two missing symbols in linking:

std::_List_node_base::_M_hook(std::_List_node_base*)
std::_List_node_base::_M_unhook()

libstdc++.so from 4.5.0 has those relevant symbols, and the ones not found are there:
000584c4 T std::_List_node_base::_M_hook(std::_List_node_base*)
000585bc T std::__norm::_List_node_base::_M_hook(std::__norm::_List_node_base*)
000ab3c8 T std::__cxx1998::_List_node_base::_M_hook(std::__cxx1998::_List_node_base*)
000584e0 T std::_List_node_base::_M_unhook()
000585d8 T std::__norm::_List_node_base::_M_unhook()
000ab3e4 T std::__cxx1998::_List_node_base::_M_unhook()
Comment 1 Paolo Carlini 2010-04-25 00:28:12 UTC 
Thus the symbols are there, and exported (ie, capital T), everything seems fine to me.
Comment 2 Yuri 2010-04-25 00:35:55 UTC 
But linker produces messages like this:
x.C:229: undefined reference to `std::_List_node_base::_M_hook(std::_List_node_base*)'

New with the switch to 4.5.0
Comment 3 Paolo Carlini 2010-04-25 00:37:23 UTC 
Thus, either the linker is buggy, or the installation.
Comment 4 Paolo Carlini 2010-04-25 00:40:54 UTC 
Note, those symbols are new in 4.5.0, thus you should check that your new 4.5.0 *.so is actually searched by linker, ie, check the installation, again, because if the linker tries to link vs the 4.4.x *.so the symbols will not be found.
Comment 5 Yuri 2010-04-25 01:17:04 UTC 
Sorry, my bad.

It really was picking up the default libstdc++.so from the OS installation. I used -R/path/to/4.5.0/libstdc++.so to fix this library path. But it turns out that -L/path/to/4.5.0/libstdc++.so is also required in addition to this, otherwise the default libstdc++.so is looked up by linker.

Maybe this is a bug in linker, don't know.

But those new symbols revealed the problem.
Comment 6 Paolo Carlini 2010-04-25 04:49:33 UTC 
Ok, thanks, let's close this then.
Comment 7 Jonathan Wakely 2010-04-25 20:31:04 UTC 
(In reply to comment #5)
> 
> It really was picking up the default libstdc++.so from the OS installation. I
> used -R/path/to/4.5.0/libstdc++.so to fix this library path. But it turns out
> that -L/path/to/4.5.0/libstdc++.so is also required in addition to this,
> otherwise the default libstdc++.so is looked up by linker.
> 
> Maybe this is a bug in linker, don't know.

No, that's the expected behaviour