[reSIProcate] Extreme link problem
Hello resip,
After some trial and error, I think this is a basic linker issue, so any
linker guru can probably help.
To review, I need to link libresip, librutil, and libares into my SIP
application so I can use the DNS lookup classes. My app uses JTC
(Java-style thread classes) and RogueWave, and did not previously need
libstdc++. When I link in the resip libs and stdc++, the link completes
fine but I get the crashes below at runtime. Jason suggested I compile/link
the resip libs against JTC and RogueWave as well. After several ugly #ifdef
hacks I got that done, but still get the same runtime error.
Here's what I think is happening. Prior to adding the resip code, there
were some symbols loaded at runtime like the ~ostrstream destructor. Soon
as I add libstdc++ to my link, the stdc++ version of that symbol is now
built into my main binary, and it's not picked up from libJTC.so at runtime
any more. The JTC code apparently does not like the stdc++ version of the
ostrstream code, and blows up. (Interestingly, the stdc++ method turns
around and calls RogueWave code, but the damage is probably already done.)
See the nm output below, where the libJTC version is "W" and the libstdc++
version is "T".
Is there a way to force the linker not to pull in specified symbols? That
way, I could pull in the JTC code at runtime as before. I've already tried
all possible games with the link order and grouping, and none work - if the
symbols exist anywhere in the linked libraries, they'll get pulled in.
Hopefully, if I statically link the resip libraries against stdc++ (no JTC
or RW), they'll mix OK with my other code, so I won't need to use my hacked
resip code.
My linker ld version 2.12.1 doesn't support --disable-stdcall-fixup or
--exclude-symbols. :(
Regards,
Dave
Original working version:
$ nm SmSipMgr.5002 | grep ostrstream
0808335c W _ZNKSt10ostrstream5rdbufEv
0808290e W _ZNSt10ostrstreamC1EPcii
0808329c W _ZNSt10ostrstreamD0Ev
0808284e W _ZNSt10ostrstreamD1Ev
0818c200 V _ZTCSt10ostrstream0_So
0818c2c8 V _ZTISt10ostrstream
08145b37 V _ZTSSt10ostrstream
0818c1f0 V _ZTTSt10ostrstream
0818c240 V _ZTVSt10ostrstream
0808332e W _ZTv0_n12_NSt10ostrstreamD0Ev
080828e0 W _ZTv0_n12_NSt10ostrstreamD1Ev
integrated version that crashes:
$ nm SmSipMgr | grep ostrstream
w _ZNKSt10ostrstream5rdbufEv@@GLIBCPP_3.2
08087f46 W _ZNSt10ostrstreamC1EPcii
w _ZNSt10ostrstreamD0Ev@@GLIBCPP_3.2
w _ZNSt10ostrstreamD1Ev@@GLIBCPP_3.2
082951e0 V _ZTCSt10ostrstream0_So
082952a8 V _ZTISt10ostrstream
082347f7 V _ZTSSt10ostrstream
082951d0 V _ZTTSt10ostrstream
08295220 V _ZTVSt10ostrstream
08088966 W _ZTv0_n12_NSt10ostrstreamD0Ev
08087f18 W _ZTv0_n12_NSt10ostrstreamD1Ev
$ nm lib/libJTC.so.1.0.14 | grep ostrstream
0000a554 W _ZNKSt10ostrstream5rdbufEv
00009db6 W _ZNSt10ostrstreamC1EPcii
0000a494 W _ZNSt10ostrstreamD0Ev
00009cf6 W _ZNSt10ostrstreamD1Ev
0001a640 V _ZTCSt10ostrstream0_So
0001a6c0 V _ZTISt10ostrstream
00017f20 V _ZTSSt10ostrstream
0001a618 V _ZTTSt10ostrstream
0001a680 V _ZTVSt10ostrstream
0000a526 W _ZTv0_n12_NSt10ostrstreamD0Ev
00009d88 W _ZTv0_n12_NSt10ostrstreamD1Ev
$ nm libstdc++.so | grep ostrstream
0007cf8e T _ZNKSt10ostrstream5rdbufEv
0007cff6 T _ZNKSt10ostrstream6pcountEv
0007cfcc T _ZNSt10ostrstream3strEv
0007cf9a T _ZNSt10ostrstream6freezeEb
0007ccd6 T _ZNSt10ostrstreamC1EPciSt13_Ios_Openmode
0007caf4 T _ZNSt10ostrstreamC1Ev
0007cbe2 T _ZNSt10ostrstreamC2EPciSt13_Ios_Openmode
0007ca32 T _ZNSt10ostrstreamC2Ev
0007cee6 T _ZNSt10ostrstreamD0Ev
0007ce46 T _ZNSt10ostrstreamD1Ev
0007cdf2 T _ZNSt10ostrstreamD2Ev
00096e00 d _ZTCSt10ostrstream0_So
00096f78 V _ZTISt10ostrstream
0008f062 V _ZTSSt10ostrstream
00096de0 V _ZTTSt10ostrstream
00096e40 V _ZTVSt10ostrstream
0007cf62 W _ZTv0_n12_NSt10ostrstreamD0Ev
0007ceba W _ZTv0_n12_NSt10ostrstreamD1Ev
$ nm libstdc++.a | grep ostrstream
00000000 T _ZNKSt10ostrstream5rdbufEv
00000000 T _ZNKSt10ostrstream6pcountEv
00000000 T _ZNSt10ostrstream3strEv
00000000 T _ZNSt10ostrstream6freezeEb
00000000 T _ZNSt10ostrstreamC1EPciSt13_Ios_Openmode
00000000 T _ZNSt10ostrstreamC1Ev
00000000 T _ZNSt10ostrstreamC2EPciSt13_Ios_Openmode
00000000 T _ZNSt10ostrstreamC2Ev
00000000 T _ZNSt10ostrstreamD0Ev
00000000 T _ZNSt10ostrstreamD1Ev
00000000 T _ZNSt10ostrstreamD2Ev
00000000 V _ZTCSt10ostrstream0_So
00000000 V _ZTISt10ostrstream
00000000 V _ZTSSt10ostrstream
00000000 V _ZTTSt10ostrstream
00000000 V _ZTVSt10ostrstream
00000000 W _ZTv0_n12_NSt10ostrstreamD0Ev
00000000 W _ZTv0_n12_NSt10ostrstreamD1Ev
-----Original Message-----
From: jason.fischl@xxxxxxxxx [mailto:jason.fischl@xxxxxxxxx] On Behalf Of
Jason Fischl
Sent: Tuesday, December 19, 2006 12:54 PM
To: Dave Mason
Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
Subject: Re: [reSIProcate] Extreme link problem
It sounds like you are compiling against one set of include files and
linking against a different library. Make sure you build resip with the same
include paths as your application.
On 12/19/06, Dave Mason <Dave.Mason@xxxxxxxxxxx> wrote:
> 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
>