Hail! I've been trying to use boost python with the msvc 6.0 compiler and STLport-4.5.3 for two weeks now, without success. I've read the tutorial, and created a short snippet to export a simple class that represents color information. I compiled boost without problems (using the "msvc-stlport" toolset), and I'm using Python 2.2 (ActiveState's distribution). I'm using a msvc project to build a DLL, and during the linking stage it complains about the following unresolved externals: void boost::python::objects::register_dynamic_id_aux(...) class boost::python::api::object __cdecl boost::python::objects::function_object Plus, it gives some warnings about: "non dll-interface class 'boost::noncopyable' used as base for dll-interface struct 'boost::python::instance_holder'" I've also done the same tests using the Intel 6.0 compiler, and it gives the same unresolved externals, but no warnings. I didn't compile boost with Intel and STLport support because I couldn't find in the documentation a tool to do it, but would like to do it, since I don't plan to use the msvc compiler, which was used just for the sake of this tests. I plan also to create a static library for embedding purposes, so that I can link this library with a program, and use the objects exported by it. To do this, I compile the lib with the flag BOOST_PYTHON_STATIC_LIB, and it gives 2 warnings (about int being cast to bool), and in the main() of the program I call the function initmymodule() (there's a better way to do this?). When I try to compile my application thought, it gives the same unresolved externals above. On the other hand, If I don't use STLport (including compiling boost with the "msvc" toolset), everything works as expected, both the DLL and the embeded application. What can I do to successfuly compile both the application and the DLL? Any pointer will be great! Thanks a lot, Nicodemus.
"Nicodemus" <nicodemus@globalite.com.br> writes:
Hail!
I've been trying to use boost python with the msvc 6.0 compiler and STLport-4.5.3 for two weeks now, without success.
I've read the tutorial, and created a short snippet to export a simple class that represents color information. I compiled boost without problems (using the "msvc-stlport" toolset), and I'm using Python 2.2 (ActiveState's distribution). I'm using a msvc project to build a DLL, and during the linking stage it complains about the following unresolved externals:
Did you try using Boost.Build to create your DLL? Usually when people have trouble building or linking their Boost.Python projects it's because they don't set up their build environment to do what Boost.Build would do; they get the build instructions wrong... If you invoke Boost.Build with the "-n -a" options it will just dump all the build commands it runs so you can inspect the command-line options. On the other hand, MSVC6 is reknowned for its many bugs, so you might just be running into a problem with your tools.
void boost::python::objects::register_dynamic_id_aux(...) class boost::python::api::object __cdecl boost::python::objects::function_object
These are exported from libs/python/src/object/inheritance.cpp and libs/python/src/object/function.cpp, respectively.
Plus, it gives some warnings about: "non dll-interface class 'boost::noncopyable' used as base for dll-interface struct 'boost::python::instance_holder'"
You can ignore that warning.
I've also done the same tests using the Intel 6.0 compiler, and it gives the same unresolved externals, but no warnings.
Did you rebuild the Boost.Python library with Intel 6.0, or are you trying to use the same one you built with MSVC6?
I didn't compile boost with Intel and STLport support because I couldn't find in the documentation a tool to do it, but would like to do it, since I don't plan to use the msvc compiler, which was used just for the sake of this tests.
An advantage of Intel + STLPort is that you can turn off the "microsoft bug emulation mode" in the Intel compiler to get a very high degree of standard conformance.
I plan also to create a static library for embedding purposes, so that I can link this library with a program, and use the objects exported by it. To do this, I compile the lib with the flag BOOST_PYTHON_STATIC_LIB, and it gives 2 warnings (about int being cast to bool), and in the main() of the program I call the function initmymodule() (there's a better way to do this?). When I try to compile my application thought, it gives the same unresolved externals above.
That's awfully strange. Does Intel give any more-detailed information about which source files (or preferably functions) are asking for these symbols?
On the other hand, If I don't use STLport (including compiling boost with the "msvc" toolset), everything works as expected, both the DLL and the embeded application.
What can I do to successfuly compile both the application and the DLL? Any pointer will be great!
I suggest that you start with a small example using Boost.Build. -- David Abrahams dave@boost-consulting.com * http://www.boost-consulting.com
Did you try using Boost.Build to create your DLL? Usually when people have trouble building or linking their Boost.Python projects it's because they don't set up their build environment to do what Boost.Build would do; they get the build instructions wrong... I did compile the simple hello world example, but didn't investigate in this
Hail, thanks for the quick response. David Abrahams <dave@boost-consulting.com> wrote: path further because building the extensions using Boost.Build was not desired, because we plan to use it at work and we have other build system. After your suggestion, I did compile my extension with Boost.Build, and it did work perfectly.
If you invoke Boost.Build with the "-n -a" options it will just dump all the build commands it runs so you can inspect the command-line options. Great, I was looking for this. Thanks.
On the other hand, MSVC6 is reknowned for its many bugs, so you might just be running into a problem with your tools. Indeed, and I was using it only because I wanted to compile boost with stlport, and there's no toolset to compile intel+stlport.
Did you rebuild the Boost.Python library with Intel 6.0, or are you trying to use the same one you built with MSVC6? I didn't rebuild Boost.Python with Intel 6, because I wanted to build it using STLport.
That's awfully strange. Does Intel give any more-detailed information about which source files (or preferably functions) are asking for these symbols? Unfortunetely, no. But here it is the complete error for one of the functions: rgba.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) void __cdecl boost::python::objects::register_dynamic_id_aux(struct boost::python::type_info,struct _STL::pair<void *,struct boost::python::type_info> (__cdecl*)(void *))" ( __imp_?register_dynamic_id_aux@objects@python@boost@@YAXUtype_info@23@P6A?AU?$ pair@PAXUtype_info@python@boost@@@_STL@@PAX@Z@Z)
I suggest that you start with a small example using Boost.Build. Thanks, I will do just that.
One thing that I noticed after analyzing the command line generated by Boost.Build is that I was not specifying the path to my stlport instalation correctly! I corrected this, but now the msvc compiler gives internal errors while parsing one of the stlport's headers, _complex.h. 8( So, the previous unresolved externals where the result of the mixing of STLport and the msvc stl implementation, because like I said previously, if I compiled without STLport everything worked. I then compiled everything with Intel 32, without STLport, and Alas!, everything works nicely. (except one detail: like I said before, to embed the code in one executable, I compiled the static lib with BOOST_PYTHON_STATIC_LIB, which was giving me one unresolved external. After I removed this define, it compiled and linked without any error or warning). After all this, another question then: How can I compile Boost.Python using the Intel compiler and STLport? Unfortunetely, using the native msvc stl libraries is not an option for me. Thanks again for the help David! Nicodemus.
"Nicodemus" <nicodemus@globalite.com.br> writes:
Hail, thanks for the quick response.
You're welcome. It would be easier to read your replies if you'd leave a blank line after quoted text.
David Abrahams <dave@boost-consulting.com> wrote:
On the other hand, MSVC6 is reknowned for its many bugs, so you might just be running into a problem with your tools. Indeed, and I was using it only because I wanted to compile boost with stlport, and there's no toolset to compile intel+stlport.
Huh? What's wrong with http://www.boost.org/tools/build/intel-win32-stlport-tools.jam?
Did you rebuild the Boost.Python library with Intel 6.0, or are you trying to use the same one you built with MSVC6?
I didn't rebuild Boost.Python with Intel 6, because I wanted to build it using STLport.
In theory, Intel is supposed to produce code that's link-compatible with that produced by msvc6. However in general that's not true of C++ compilers and I wouldn't be at all surprised to find out that it fails in corner cases for msvc6 and Intel C++.
That's awfully strange. Does Intel give any more-detailed information about which source files (or preferably functions) are asking for these symbols?
Unfortunetely, no. But here it is the complete error for one of the functions: rgba.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) void __cdecl boost::python::objects::register_dynamic_id_aux(struct boost::python::type_info,struct _STL::pair<void *,struct boost::python::type_info> (__cdecl*)(void *))" ( __imp_?register_dynamic_id_aux@objects@python@boost@@YAXUtype_info@23@P6A?AU?$ pair@PAXUtype_info@python@boost@@@_STL@@PAX@Z@Z)
Oh, that's very different: your previous message seemed to indicate that 3 symbols were missing. This is just one symbol. Unfortunately, it doesn't change my response.
I suggest that you start with a small example using Boost.Build.
Thanks, I will do just that.
One thing that I noticed after analyzing the command line generated by Boost.Build is that I was not specifying the path to my stlport instalation correctly! I corrected this, but now the msvc compiler gives internal errors while parsing one of the stlport's headers, _complex.h. 8( So, the previous unresolved externals where the result of the mixing of STLport and the msvc stl implementation, because like I said previously, if I compiled without STLport everything worked.
Yeah, that seems plausible. In particular, it was the confusion about std::pair vs _STL::pair.
I then compiled everything with Intel 32, without STLport, and Alas!, everything works nicely.
Why "alas"? Do you lament the fact that it's working?
(except one detail: like I said before, to embed the code in one executable, I compiled the static lib with BOOST_PYTHON_STATIC_LIB, which was giving me one unresolved external. After I removed this define, it compiled and linked without any error or warning).
Is there a reason you need static linking? Dynamically linking to the boost_python dll should still work for embedding.
After all this, another question then: How can I compile Boost.Python using the Intel compiler and STLport? Unfortunetely, using the native msvc stl libraries is not an option for me.
Use the supplied toolset? -- David Abrahams dave@boost-consulting.com * http://www.boost-consulting.com
"David Abrahams" <dave@boost-consulting.com> wrote:
Indeed, and I was using it only because I wanted to compile boost with stlport, and there's no toolset to compile intel+stlport.
Huh? What's wrong with http://www.boost.org/tools/build/intel-win32-stlport-tools.jam?
Nothing, except that I didn't know it existed. <wink> Seriously, I didn't found it mentioned in the documentation, but I should've searched more. Thanks for the pointer.
I didn't rebuild Boost.Python with Intel 6, because I wanted to build it using STLport.
In theory, Intel is supposed to produce code that's link-compatible with that produced by msvc6. However in general that's not true of C++ compilers and I wouldn't be at all surprised to find out that it fails in corner cases for msvc6 and Intel C++.
Indeed, we had some linkage problems while mixing object code compiled with intel and msvc.
Unfortunetely, no. But here it is the complete error for one of the functions: rgba.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) void __cdecl boost::python::objects::register_dynamic_id_aux(struct boost::python::type_info,struct _STL::pair<void *,struct boost::python::type_info> (__cdecl*)(void *))" (
__imp_?register_dynamic_id_aux@objects@python@boost@@YAXUtype_info@23@P6A?AU?$
pair@PAXUtype_info@python@boost@@@_STL@@PAX@Z@Z)
Oh, that's very different: your previous message seemed to indicate that 3 symbols were missing. This is just one symbol. Unfortunately, it doesn't change my response.
Sorry for not making myself clear, but this is the error message for just one of the symbols.
I then compiled everything with Intel 32, without STLport, and Alas!, everything works nicely.
Why "alas"? Do you lament the fact that it's working?
Ops! English is not my native language, and I thought "Alas" meant something along the lines of "Ahá!"... sorry about that! ;)
(except one detail: like I said before, to embed the code in one executable, I compiled the static lib with BOOST_PYTHON_STATIC_LIB, which was giving me one unresolved external. After I removed this define, it compiled and linked without any error or warning).
Is there a reason you need static linking? Dynamically linking to the boost_python dll should still work for embedding.
Oh, sorry again for not making myself clear: I compiled MY static library with BOOST_PYTHON_STATIC_LIB, supposing that would solve the unresolved externals. But as I understand now, this flag should be set only while build Boost.Python for static linking, right?
After all this, another question then: How can I compile Boost.Python using the Intel compiler and STLport? Unfortunetely, using the native msvc stl libraries is not an option for me.
Use the supplied toolset?
Hehe, indeed. And I did just that. Everything worked perfectly. 8) Thanks again for your time and patience! Farewell, Nicodemus.
"Nicodemus" <nicodemus@globalite.com.br> writes:
Oh, sorry again for not making myself clear: I compiled MY static library with BOOST_PYTHON_STATIC_LIB, supposing that would solve the unresolved externals. But as I understand now, this flag should be set only while build Boost.Python for static linking, right?
Right. -- David Abrahams dave@boost-consulting.com * http://www.boost-consulting.com
participants (2)
-
David Abrahams -
Nicodemus