< Previous by Date Date Index Next by Date >
  Thread Index Next in Thread >

[reSIProcate] Extreme link problem


Hi,

I'm not sure how extreme this is, but I'm ready to grasp at straws, so I
thought I'd see if anybody here has an idea.  I already have a SIP app that
uses RogueWave and JThreads/C++ (JTC), a thread class library.  Those two
together have a lot of stuff that ordinarily comes from libstdc++, so that
library is not currently linked into the app.  I have a wrapper class that
calls the reSIProcate DNS lookup code, and am not using the rest of the
resip stack.

When I add -lresip -lrutil -lares, along with my wrapper, it wont link
unless I add -lstdc++ at the end.  Then it links fine but crashes at
runtime.  I'll include the stack trace and link line below.  The CORBA stuff
is Orbacus but I don't figure that's causing a problem.  On looking around,
I see the ~ostrstream destructor comes from the JTC library in the original
link, but now it comes from stdc++.  It seems like no matter what I do with
the link order, it always comes from stdc++.

Is there a way to build the resip stuff as a subset or group that is linked
against stdc++, while the rest of the program is linked as before?  I
considered building the resip code and libraries into a new .a archive, then
linking that into my program, but I wonder if the stdc++ symbols would still
get pulled in.

Thanks for any ideas you might have,
Dave

(gdb) where
#0  0x415646ff in __rw_atomic_add () from
/opt/genband/5.0.0.0/lib/libstd3112d.so
#1  0x4155c0e7 in std::locale::~locale() () from
/opt/genband/5.0.0.0/lib/libstd3112d.so
#2  0x41561161 in std::strstreambuf::~strstreambuf() () from
/opt/genband/5.0.0.0/lib/libstd3112d.so
#3  0x419d3e82 in ~ostrstream (this=0xbfffedb4) at
../../../../libstdc++-v3/src/strstream.cc:372
#4  0x41945799 in JTCThread::setName(char const*) (this=0x832a4f0,
name=0xbfffee10 "`\\\001@A") at Thread.cpp:638
#5  0x4194409c in JTCThread (this=0x832a4f0, id={id_ = 1024, nullId_ =
false}, main=true) at Thread.cpp:523
#6  0x41947284 in JTCInitialize::initialize() (this=0x832a468) at
Thread.cpp:1483
#7  0x419473bc in JTCInitialize (this=0x832a468) at Thread.cpp:1496
#8  0x406663f0 in ORBInstanceS (this=0x832a408) at ORBInstanceS.cpp:198
#9  0x406677d4 in OB::ORBMemberFactory::createORBInstance() () at
ORBMemberFactoryS.cpp:27
#10 0x406ca824 in ORB (this=0x832a358, ac=3, av=0xbffff724, id=0x832a178 "",
coreTraceLevels=0x832a328, properties=0x832a110,
    logger=0x832a048) at OBORB.cpp:184
#11 0x406cc221 in ORB (this=0x832a358, ac=3, av=0xbffff724, id=0x832a178 "",
coreTraceLevels=0x832a328, properties=0x832a110,
    logger=0x832a048) at OBORB.cpp:529
#12 0x406cff0d in OBCORBA::ORB_init(int&, char**, OB::Properties*,
OB::Logger*, char const*, char const*) (ac=@0xbffff6d0,
    av=0xbffff724, properties=0x832a110, logger=0x832a048,
orb_identifier=0x82416a7 "", version=0x82416a8 "1.0.1")
    at ORB_init.cpp:520
#13 0x406d01e7 in CORBA::ORB_init(int&, char**, char const*, char const*)
(ac=@0xbffff6d0, av=0xbffff724,
    orb_identifier=0x82416a7 "", version=0x82416a8 "1.0.1") at
ORB_init.cpp:552
#14 0x4005784d in MainOrb::init(int&, char**, char const*, char const*)
(this=0x832a038, argc=@0xbffff6d0, argv=0xbffff724,
    orb_identifier=0x82416a7 "", version=0x82416a8 "1.0.1") at
Common/MainOrb.cpp:46
#15 0x080bfc65 in main (argc=3, argv=0xbffff724) at
Protocols/SIPManager/src/SmSIPMain.cpp:85

Linking LINUX/bin/SmSipMgr.tmp ...
pentium4-gcc -fPIC -o LINUX/bin/SmSipMgr.tmp -Wl,-Map
-Wl,LINUX/bin/SmSipMgr.tmp.map -L/externals/jtc/0.0.0.4/jtc/lib
-Wl,-R/externals/jtc/0.0.0.4/jtc/lib -L/externals/obe/0.0.1.0/obe/lib
-Wl,-R/externals/obe/0.0.1.0/obe/lib -L/externals/rmp/0.0.1.0/lib
-Wl,-R/externals/rmp/0.0.1.0/lib -L/opt/resip/lib -Wl,-R/opt/resip/lib
-LLINUX/lib -Wl,-RLINUX/lib 
<many .o files removed, including my wrapper class and code that calls it>
 -lSynCommon -lProcessCtl -lTrader -lOB -lRMP -lsip -lresip -lrutil -lares
-ltcp -lUNS -lSmFrameWork -lSmClient -lLogger -lResMgmt -lAlarm -lSIPConfig
-lDB
<many application specific libraries removed>
 -lnsl -lJTC -lpthread -L/externals/rw_mvlinux/lib -lstd3112d -lsync2312d
-lthread2312d -lfunctor2312d -litc2312d -lthrexcept2312d -ltls7712d
-lpointer2312d -lfunctor_list2312d -lsupc++ -lsacl2x45 -lm -ldl -lstdc++

If I move -lstdc++ up to follow -lares, before -lJTC, I get this:

(gdb) where
#0  0x41a7ab17 in __libc_free (mem=0xbfffee98) at malloc.c:3142
#1  0x4009cd2b in operator delete(void*) (ptr=0xbff00000) at
../../../../libstdc++-v3/libsupc++/del_op.cc:39
#2  0x4009cd87 in operator delete[](void*) (ptr=0xbff00000) at
../../../../libstdc++-v3/libsupc++/del_opv.cc:36
#3  0x4005e75e in ~ios_base (this=0xbfffee90) at
../../../../libstdc++-v3/src/ios.cc:308
#4  0x40093eaf in ~ostrstream (this=0xbfffee90)
    at
/var/tmp/BUILD/gcc-3.2/objdir/i686-hardhat-linux/libstdc++-v3/include/bits/b
asic_ios.h:130
#5  0x4069a799 in JTCThread::setName(char const*) (this=0x8327d30,
name=0xbfffee10 "") at Thread.cpp:638