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

Re: [reSIProcate] Extreme link problem


Thanks for the tip, I think that's the right direction to go.  I'm now
trying to rebuild reSIProcate v1.0.2 against Roguewave and JTC.  The problem
I'm running into now is a case in rutil/HashMap.hxx where there's an ifdef
that forces another include of <ext/hash_map> if the compiler is gcc v3.1 or
greater.  I'm on 3.2.1 so I get this error.  Is there a symbol or something
I need to redefine?  I suspect there may be others like this when I get past
here.

Dave

make[1]: Entering directory
`/home/dmason/sip/resiprocate/resiprocate-1.0.2/rutil'^M
g++ -march=i686 -D_REENTRANT  -g  -Wall -I..
-I../build/../contrib/ares -I/externals/rw_mvlinux
-I/externals/rw_mvlinux/include -I/externals/jtc/0.0.0.4/jtc/include
-DUSE_ARES -D_RWCONFIG=12d -DLINUX -DRW_CLASSIC_TEMPLATE_CONTAINERS -c -o
obj.debug.Linux.i686/AbstractFifo.o AbstractFifo.cxx^M
In file included from /usr/include/c++/3.2.1/bits/stl_algobase.h:71,^M
                 from /usr/include/c++/3.2.1/ext/stl_hashtable.h:68,^M
                 from /usr/include/c++/3.2.1/ext/hash_map:65,^M
                 from ../rutil/HashMap.hxx:7,^M
                 from ../rutil/Data.hxx:10,^M
                 from AbstractFifo.cxx:3:^M
/usr/include/c++/3.2.1/bits/stl_pair.h:69: redefinition of `struct ^M
   std::pair<_TypeT, _TypeU>'^M
/externals/rw_mvlinux/include/rw/_pair.h:59: previous definition of `struct
^M
   std::pair<_TypeT, _TypeU>'^M
/usr/include/c++/3.2.1/bits/stl_pair.h:94: redefinition of `template<class
_T1, ^M
   class _T2> bool std::operator==(const std::pair<_TypeT, _TypeU>&, const
^M
   std::pair<_TypeT, _TypeU>&)'^M
/externals/rw_mvlinux/include/rw/_pair.h:101: `template<class _TypeT, class
^M
   _TypeU> bool std::operator==(const std::pair<_TypeT, _TypeU>&, const ^M
   std::pair<_TypeT, _TypeU>&)' previously declared here^M
Etc., many more....

I added a package to build/Makefile.pkg that looks like this, and added it
to PACKAGES after ARES in the various Makefiles.

GB_INCLUDEDIRS := /externals/rw_mvlinux /externals/rw_mvlinux/include
/externals/jtc/0.0.0.4/jtc/include
GB_LIBDIRS := /externals/jtc/0.0.0.4/jtc/lib /externals/rw_mvlinux/lib
GB_LIBNAME := JTC std3112d sync2312d thread2312d functor2312d itc2312d
threxcept2312d tls7712d pointer2312d functor_list2312d supc++
GB_DEFINES := _RWCONFIG=12d LINUX RW_CLASSIC_TEMPLATE_CONTAINERS


-----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
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>