[C++-sig] Nasty Heap Error in MSVC 7.1 WithBoost andPythonUsing Derived Classes
mjkeyes at sbcglobal.net
mjkeyes at sbcglobal.net
Wed Oct 19 03:33:41 CEST 2005
I thought that at first, too. I've done a search on my entire computer
for every boost_python* file there is and deleted them, but the error
remains after I build again with bjam.
I'm going to look into it a bit further tonight and see if I can find
any other differences. Thanks for all the help guys.
"David Abrahams" <dave at boost-consulting.com> wrote in message
news:<ull0qij2v.fsf at boost-consulting.com>...
> "Matthew B. Keyes" <Keyes at simcrest.com> writes:
> > Here is how I built my extension/embedded application and extension
> > dll with MS Visual Studio .NET 2003:
> > -Use the MSVC project supplied with Boost.Python to build
> > boost_python.dll -Link to the boost_python.lib file for both
> > projects -Build (and everything works fine and runs well)
> > Now, in trying to add the import function, I retrieved the latest
> > Boost files from CVS. I initially tried to use the supplied MSVC
> > project to build the boost_python.dll, but I received linking errors
> > when I use the import function. Thus, I fired up bjam and let it
> > build the boost_python.dll file. However, when I rebuild my project
> > that uses import (the extension/embedded application), I still
> > receive the linking error. If I add import.cpp to the project, the
> > linking error goes away.
> > I tried looking at the exec.cpp test applet via bjam, but I receive
> > several errors on some of the other applets and it is very difficult
> > to filter out all the command line chatter to see what happened with
> > the exec applet. That said, I do take your word for it that it
> > works.
> > The specific linking error I receive is this:
> > error LNK2019: unresolved external symbol "class
> > boost::python::api::object __cdecl boost::python::import(class
> > boost::python::str)"
> > (?import at python@boost@@YA?AVobject at api@12 at Vstr@12@@Z) referenced in
> > function "public: virtual bool __thiscall
> > PythonLib::PythonLibObjectContainer::CreateInstanceOfObject(class
> > std::basic_string<char,struct std::char_traits<char>,class
> > std::allocator<char> > const &,class std::basic_string<char,struct
> > std::char_traits<char>,class std::allocator<char> > const &)"
> > (?CreateInstanceOfObject at PythonLibObjectContainer@PythonLib@@UAE_NAB
> > V?$b
> > asic_string at DU?$char_traits at D@std@@V?$allocator at D@2@@std@@0 at Z)
> Then you're clearly linking with the old library you built with the
> IDE and not the one you built with bjam.
> Dave Abrahams
> Boost Consulting
More information about the Cplusplus-sig