It was a linking problem. Our system is very basterdized. We have pure version at other locations, but /usr/lib is in VERY bad shape. After I used explicit paths it worked ok. ldd helped me to figure this out.
Thanks very much.
On Thu, 24 Mar 2005, Steven N. Hirsch wrote:
On Wed, 23 Mar 2005, Billy Patton wrote:
Found these porblems with undefined symbol
nm blib/arch/auto/Laff/Laff.so | grep tree_insert_and_rebalance U _ZSt29_Rb_tree_insert_and_rebalancebPSt18_Rb_tree_node_baseS0_RS_@@GLIBCXX_3.4 from man nm : "U" The symbol is undefined.
nm /apps/gcc/3.4.1/lib/libstdc++.so | grep tree_insert_and_rebalance 0004dc30 T _ZSt29_Rb_tree_insert_and_rebalancebPSt18_Rb_tree_node_baseS0_RS_
So if it is in libstdc++.so and I specificall put -lstdc++ at the end, shouldn't this have ld pick ip up (BTW I'm linking with g++)
Billy,
Is it possible that you have more than one libstdc++* versions in your load path? I've spent a lot of time fighting with problems similar to this on Linux, only to find that the module was not getting linked against the lib I thought it was.
What does 'ldd' tell you about the final .so file?
___ _ ____ ___ __ __
/ _ )(_) / /_ __ / _ \___ _/ /_/ /____ ___
/ _ / / / / // / / ___/ _ `/ __/ __/ _ \/ _ \
/____/_/_/_/\_, / /_/ \_,_/\__/\__/\___/_//_/
/___/ Texas Instruments ASIC Circuit Design Methodology Group
Dallas, Texas, 214-480-4455, [EMAIL PROTECTED]
