Re: [reSIProcate] Extreme link problem
Guess this is a generic linker question for anybody who may know. I started
off hacking HashMap.hxx to force it to use the last #else so it would
compile, then proceeded down a similar chain of hacks to get other stuff to
compile.
This is starting to seem like a bad plan. Is there a way to build the resip
libraries with the normal make, then use some special grouping to force my
final link to use the non-resip libraries for non-resip code? This way, my
existing code would not try to resolve any symbols in the resip "group" if
they can be resolved elsewhere. (I tried shifting the link order around a
zillion ways but that alone never worked.) I have a wrapper class in my
other code that reaches down into resip, but everything else should be
isolated. I'm not using shared libs, so the resip libraries are all .a's.
Regards,
Dave
-----Original Message-----
From: Dave Mason
Sent: Tuesday, December 19, 2006 5:54 PM
To: 'Jason Fischl'
Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
Subject: 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
>