[EMAIL PROTECTED] writes: > Finally after a long struggle to fix this problem, i have figured out a > work around..
Good for you. Of course, there is no telling what *else* may be broken. > How does it make the difference when instantiate a template class as > local variable instead of as member variable of that class. Well, the compiler obviously emits different code. Whatever the bug was, it is not tickled by your workaround. > Now i am facing new problem. Our application is quite huge. > we use 3rd party SDK which is interfaced with our applciation. > it is link with this 3rd party library with one my execuatables. > During run time this executable i am getting unsatisfied symbol as > > ld: (Warning) Unsatisfied symbol "__cxa_personality_routine"..... from > this library. That's somewhat strange -- usually unsatisfied symbols like this are fatal and cause immediate abort. > when browse for this symbol i came to know that it is because of mix of > libraries of which were built using gcc/g++ and aCC. The 3rd party > library was built using aCC ( we cant do anything with this.) C++ code compiled by different compilers is *not* link compatible. You shouldn't expect the app to link at all. But perhaps you are doing a dlopen() on the 3rd party library? In that case, it will merely "not work". > My application is quite huge and build already completed using g++ and > i cant rebuild using aCC and i am already in testing phase. Is there > any work around to fix this problem... No. You should have checked what your dependencies are *before* you started building your app. Cheers, -- In order to understand recursion you must first understand recursion. Remove /-nsp/ for email. _______________________________________________ help-gplusplus mailing list help-gplusplus@gnu.org http://lists.gnu.org/mailman/listinfo/help-gplusplus
