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
>