[python] python 3 with boost 1.44, without using bjam
I'm working on a DLL that I would like to expose to Python as a module, but as I came into Python only when Python 3 was available, that's what I know and therefore would like to use. A while ago I took a stab at learning bjam, but for now I've reverted to regular msvc projects, I was able to compile boost.python initially with bjam when I updated to Boost 1.44, the result generated the following files of relevance: libboost_python3-vc90-mt-1_44.lib libboost_python3-vc90-mt.lib libboost_python3-vc90-mt-sgd-1_44.lib libboost_python3-vc90-mt-sgd.lib which is great.. but when I try to compile my project it looks for libboost_python-vc90-mt-1_44.lib or libboost_python-vc90-mt-gd-1_44.lib as appropriate. How can I make msvc compile it successfully? I know bjam is a compiler driver, so I imagine there's a way... (FYI, here are the compilation commands I use from a batch file when compiling a new boost release. I used to use the recommended commands but they stopped working when boost changed the naming conventions to use version-independent naming, probably because I hadn't modified project settings in some way, but a lot of projects would get effected, so after some fiddling this is what I came up with). start bjam --toolset=msvc variant=debug link=static threading=multi runtime-link=static stage start bjam --toolset=msvc variant=release link=static threading=multi runtime-link=shared stage Many thanks, Geoff Unrelatedly, a comment I think might be interesting (if only speculative): from what I recall, I think boost was partially influenced to switch to version-independent naming because (among other reasons) Microsoft was using the version-independence way of thinking via the .Net model with the GAC, but I found an article at one point (which I can no longer find) saying that they realized after much experience with .Net that it's actually still quite possible to get version/DLL conflicts as a result of the version-independence naming (I believe it had to do with GUID generation or some such thing, but don't quote me on that), and quite a lot harder to debug. As a result they would be rethinking .Net and/or changing to a model where version-dependence plays a more prominent role at some point in the future. I wish I could point out the article, but at any rate I know I remember thinking it was funny (if possibly unfortunate) that boost was switching to this new naming convention, a move partially influenced by Microsoft's current methodology in some capacity, after Microsoft had discovered this issue and would eventually be (as I understand it) reverting to what essentially equates to the traditional pre-.Net DLL where versioning can be a more important issue.
Hello,
On Thu, Sep 9, 2010 at 12:32 AM, Geoff Hilton
but for now I've reverted to regular msvc projects, I was able to compile boost.python initially with bjam when I updated to Boost 1.44, the result generated the following files of relevance: libboost_python3-vc90-mt-1_44.lib libboost_python3-vc90-mt.lib libboost_python3-vc90-mt-sgd-1_44.lib libboost_python3-vc90-mt-sgd.lib
which is great.. but when I try to compile my project it looks for libboost_python-vc90-mt-1_44.lib or libboost_python-vc90-mt-gd-1_44.lib as appropriate. How can I make msvc compile it successfully? I know bjam is a compiler driver, so I imagine there's a way...
I had a similar issue and hence decided to disable to auto linking feature in boost on Windows. It use the "#pragma" to tell the linker to link with the appropriate library when you include headers that require libraries. If it is not too much of an inconvenience, you might want to take this route. To do so: Just define BOOST_ALL_NO_LIB at workspace/solution level and add the required libraries in the respective project settings. -dhruva
On 09/09/2010 12:06 AM, dhruva wrote:
Hello,
On Thu, Sep 9, 2010 at 12:32 AM, Geoff Hilton
wrote: but for now I've reverted to regular msvc projects, I was able to compile boost.python initially with bjam when I updated to Boost 1.44, the result generated the following files of relevance: libboost_python3-vc90-mt-1_44.lib libboost_python3-vc90-mt.lib libboost_python3-vc90-mt-sgd-1_44.lib libboost_python3-vc90-mt-sgd.lib
which is great.. but when I try to compile my project it looks for libboost_python-vc90-mt-1_44.lib or libboost_python-vc90-mt-gd-1_44.lib as appropriate. How can I make msvc compile it successfully? I know bjam is a compiler driver, so I imagine there's a way...
I had a similar issue and hence decided to disable to auto linking feature in boost on Windows. It use the "#pragma" to tell the linker to link with the appropriate library when you include headers that require libraries. If it is not too much of an inconvenience, you might want to take this route.
To do so: Just define BOOST_ALL_NO_LIB at workspace/solution level and add the required libraries in the respective project settings.
-dhruva
Thanks for your response, The macro is now defined and project settings point to C:\Python31\libs\Python31.lib and $(ProgramFiles)\boost\boost_1_44_0\lib\libboost_python3-vc90-mt-1_44.lib and I get the result pasted below. Is this because the function I'm trying to expose looks like this? bool X(unsigned int, unsigned int, const double* const, const double* const, const double* const, const unsigned int* const, double* const * const); I realized afterwards that I may need to rewrite/overload the function to accept PyObject pointers, but aside from that, should it be compiling anyway? What else could I be missing? Thanks again, Geoff ComputeEntropy.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: virtual unsigned int __thiscall boost::python::objects::py_function_impl_base::max_arity(void)const " (__imp_?max_arity@py_function_impl_base@objects@python@boost@@UBEIXZ) ComputeEntropy.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: virtual __thiscall boost::python::objects::py_function_impl_base::~py_function_impl_base(void)" (__imp_??1py_function_impl_base@objects@python@boost@@UAE@XZ) ComputeEntropy.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) class boost::python::api::object __cdecl boost::python::objects::function_object(struct boost::python::objects::py_function const &)" (__imp_?function_object@objects@python@boost@@YA?AVobject@api@23@ABUpy_function@123@@Z) ComputeEntropy.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) struct _object * __cdecl boost::python::detail::init_module(char const *,void (__cdecl*)(void))" (__imp_?init_module@detail@python@boost@@YAPAU_object@@PBDP6AXXZ@Z) ComputeEntropy.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) void __cdecl boost::python::detail::scope_setattr_doc(char const *,class boost::python::api::object const &,char const *)" (__imp_?scope_setattr_doc@detail@python@boost@@YAXPBDABVobject@api@23@0@Z) ComputeEntropy.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) struct boost::python::converter::registration const & __cdecl boost::python::converter::registry::lookup(struct boost::python::type_info)" (__imp_?lookup@registry@converter@python@boost@@YAABUregistration@234@Utype_info@34@@Z) ComputeEntropy.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) struct boost::python::converter::registration const * __cdecl boost::python::converter::registry::query(struct boost::python::type_info)" (__imp_?query@registry@converter@python@boost@@YAPBUregistration@234@Utype_info@34@@Z) ComputeEntropy.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) void * __cdecl boost::python::converter::get_lvalue_from_python(struct _object *,struct boost::python::converter::registration const &)" (__imp_?get_lvalue_from_python@converter@python@boost@@YAPAXPAU_object@@ABUregistration@123@@Z) ComputeEntropy.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: struct _typeobject const * __thiscall boost::python::converter::registration::expected_from_python_type(void)const " (__imp_?expected_from_python_type@registration@converter@python@boost@@QBEPBU_typeobject@@XZ) ComputeEntropy.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) struct boost::python::converter::rvalue_from_python_stage1_data __cdecl boost::python::converter::rvalue_from_python_stage1(struct _object *,struct boost::python::converter::registration const &)" (__imp_?rvalue_from_python_stage1@converter@python@boost@@YA?AUrvalue_from_python_stage1_data@123@PAU_object@@ABUregistration@123@@Z) ComputeEntropy.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) const boost::python::objects::py_function_impl_base::`vftable'" (__imp_??_7py_function_impl_base@objects@python@boost@@6B@) ComputeEntropy.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall boost::python::objects::py_function_impl_base::py_function_impl_base(void)" (__imp_??0py_function_impl_base@objects@python@boost@@QAE@XZ)
Hi,
On Fri, Sep 10, 2010 at 1:33 AM, Geoff Hilton
ComputeEntropy.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: virtual unsigned int __thiscall boost::python::objects::py_function_impl_base::max_arity(void)const " (__imp_?max_arity@py_function_impl_base@objects@python@boost@@UBEIXZ) ComputeEntropy.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: virtual __thiscall boost::python::objects::py_function_impl_base::~py_function_impl_base(void)" (__imp_??1py_function_impl_base@objects@python@boost@@UAE@XZ) ComputeEntropy.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) class boost::python::api::object __cdecl
Based on the errors, I suspect that the linker is not picking up the boost python lib for linking! IIRC, there is a way to get the command line options that would get sent to the MSVC linker. Go to the project in which you have added the extra libraries to link with, in the same dialog box somewhere at the bottom, you can see the result of the information you set in a way it gets sent to the linker. Please examine that to see if you see "libboost_python3-vc90-mt-1_44.lib". I hope you have added the folder containing the libs in the lib search path (which translates to -L option to the linker). As a quick and dirty fix to avoid tweaking the project settings manually: Add the following line in a top level header that gets included in files that use boost.python Make sure you have the library search path set or try putting absolute path in the pragma. #pragma comment( lib, "libboost_python3-vc90-mt-1_44" ) PS: It has been over 2 years since I have worked on Windows environment and I have no access to a windows box to try things out myself. Also, I have not used boost.python and I am troubleshooting more from a generic perspective. My suggestions are based on tough memorable experiences try to solve them. My memory might be rusty. -dhruva
On 09/09/2010 11:37 PM, dhruva wrote:
Hi,
On Fri, Sep 10, 2010 at 1:33 AM, Geoff Hilton
wrote: ComputeEntropy.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: virtual unsigned int __thiscall boost::python::objects::py_function_impl_base::max_arity(void)const " (__imp_?max_arity@py_function_impl_base@objects@python@boost@@UBEIXZ) ComputeEntropy.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: virtual __thiscall boost::python::objects::py_function_impl_base::~py_function_impl_base(void)" (__imp_??1py_function_impl_base@objects@python@boost@@UAE@XZ) ComputeEntropy.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) class boost::python::api::object __cdecl
Based on the errors, I suspect that the linker is not picking up the boost python lib for linking! IIRC, there is a way to get the command line options that would get sent to the MSVC linker. Go to the project in which you have added the extra libraries to link with, in the same dialog box somewhere at the bottom, you can see the result of the information you set in a way it gets sent to the linker. Please examine that to see if you see "libboost_python3-vc90-mt-1_44.lib". I hope you have added the folder containing the libs in the lib search path (which translates to -L option to the linker).
As a quick and dirty fix to avoid tweaking the project settings manually: Add the following line in a top level header that gets included in files that use boost.python Make sure you have the library search path set or try putting absolute path in the pragma. #pragma comment( lib, "libboost_python3-vc90-mt-1_44" )
PS: It has been over 2 years since I have worked on Windows environment and I have no access to a windows box to try things out myself. Also, I have not used boost.python and I am troubleshooting more from a generic perspective. My suggestions are based on tough memorable experiences try to solve them. My memory might be rusty.
-dhruva
It definitely finds the lib. It looks like it might not be (or no longer is?) binary compatible. Any other hints would be great though! Thanks very much, Geoff
On 10/09/2010 11:34 AM, Geoff Hilton wrote:
On 09/09/2010 11:37 PM, dhruva wrote:
Hi,
On Fri, Sep 10, 2010 at 1:33 AM, Geoff Hilton
wrote: ComputeEntropy.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: virtual unsigned int __thiscall boost::python::objects::py_function_impl_base::max_arity(void)const " (__imp_?max_arity@py_function_impl_base@objects@python@boost@@UBEIXZ) ComputeEntropy.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: virtual __thiscall boost::python::objects::py_function_impl_base::~py_function_impl_base(void)"
(__imp_??1py_function_impl_base@objects@python@boost@@UAE@XZ) ComputeEntropy.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) class boost::python::api::object __cdecl
Based on the errors, I suspect that the linker is not picking up the boost python lib for linking! IIRC, there is a way to get the command line options that would get sent to the MSVC linker. Go to the project in which you have added the extra libraries to link with, in the same dialog box somewhere at the bottom, you can see the result of the information you set in a way it gets sent to the linker. Please examine that to see if you see "libboost_python3-vc90-mt-1_44.lib". I hope you have added the folder containing the libs in the lib search path (which translates to -L option to the linker).
As a quick and dirty fix to avoid tweaking the project settings manually: Add the following line in a top level header that gets included in files that use boost.python Make sure you have the library search path set or try putting absolute path in the pragma. #pragma comment( lib, "libboost_python3-vc90-mt-1_44" )
PS: It has been over 2 years since I have worked on Windows environment and I have no access to a windows box to try things out myself. Also, I have not used boost.python and I am troubleshooting more from a generic perspective. My suggestions are based on tough memorable experiences try to solve them. My memory might be rusty.
-dhruva
It definitely finds the lib. It looks like it might not be (or no longer is?) binary compatible. Any other hints would be great though!
Thanks very much, Geoff
After further thought I just realized that of course it has to be binary compatible somehow if bjam can do it since it's a compiler driver.. which means I still need to find the appropriate magic to get it to recognize python3... Again, I'd love some hints, if anyone has anymore! Thanks, Geoff
Hi,
On Fri, Sep 10, 2010 at 9:21 PM, Geoff Hilton
After further thought I just realized that of course it has to be binary compatible somehow if bjam can do it since it's a compiler driver.. which means I still need to find the appropriate magic to get it to recognize python3...
bjam is just another make (purely from a functionality perspective, not trying to disregard it in anyway). I agree that it cannot affect the binary compatibility.
Again, I'd love some hints, if anyone has anymore!
I assume you are using the same MSVC version for building boost and your application (VC90 which I think is VC 2008). Try using "depends" on the boost python DLL and ensure you have the symbols that show up in linker error. I am at a dead end now. It would help me if you can give me the command line linker syntax from your project (that is giving you the unresolved errors). Tough to troubleshoot without that information. -dhruva PS: When I am back in office (monday), I can check on a windoze box (if this remains unresolved).
participants (2)
-
dhruva
-
Geoff Hilton