Build errors when Python installation is explicitly specified

[Katie Chan]

Attempts to build 32-bits target libraries/dll of Boost.Python with MSVC running under Windows 7 x64 ends with errors. The 6 *.lib & *.dll of the form boost_python-vc*-mt* are not built.

No problems is experienced if MSVC is running under 32-bits version of Windows (XP Pro SP3 & 7 Ultimate tested), or the target is 64-bits libraries even when running under Win7 x64.

The below errors was produced with Windows 7 Ultimate x64, Visual Studio (2008 Pro & 2010 Ultimate tested), and ActiveState ActivePython (2.6 & 2.7 tested).

msvc.link.dll x86\boost\bin.v2\libs\python\build\msvc-10.0\debug\threading-multi\boost_python-vc100-mt-gd-1_44.dll

Creating library x86\boost\bin.v2\libs\python\build\msvc-10.0\debug\threading-multi\boost_python-vc100-mt-gd-1_44.lib and object x86\boost\bin.v2\libs\python\build\msvc-10.0\debug\threading-multi\boost_python-vc100-mt-gd-1_44.exp

function.obj : error LNK2001: unresolved external symbol impPyErr_Format numeric.obj : error LNK2019: unresolved external symbol impPyErr_Format referenced in function "void cdecl boost::python::numeric::`anonymous namespace'::throw_load_failure(void)" (?throw_load_failure@?A0x9a30ad83@numeric@python@boost@@YAXXZ) from_python.obj : error LNK2001: unresolved external symbol impPyErr_Format registry.obj : error LNK2001: unresolved external symbol impPyErr_Format class.obj : error LNK2001: unresolved external symbol impPyErr_Format numeric.obj : error LNK2001: unresolved external symbol impPyExc_ImportError numeric.obj : error LNK2019: unresolved external symbol impPyErr_Clear referenced in function "bool cdecl boost::python::numeric::`anonymous namespace'::load(bool)" (?load@?A0x9a30ad83@numeric@python@boost@@YA_N_N@Z) class.obj : error LNK2001: unresolved external symbol impPyErr_Clear <snip>

[Katie Chan]

Build log

[rwebb <richard.webb@…>]

Are you using a 64bit version of Python? If so, the problem might be that you only have a 64bit version of python.lib, which 32bit libs can't link with.

You can get similar problems if you try to build a 64bit version of Boost and only have a 32bit version of Python installed.

[Katie Chan]

Yeah, that appears to be the problem. However, a problem that arise now is if I explicitly specified a location for Python installation (because we now have multiple Python installations), then I can't do a `bjam --build-type=complete -j2 stage' to build everything with a single command.

An error of "error: link=shared together with runtime-link=static is not allowed" pops up that doesn't otherwise arise if Python is not explicitly specified.

[Dave Abrahams]

I think this should be considered a Boost.Build problem; if you disagree, Volodya, let's discuss it.

[Vladimir Prus]

Could you please attach your user-config.jam, so that I can know exactly how you configure 32-bit Python?

Thanks, Volodya

[Katie Chan]

Well it's usually in site-config.jam rather than user-config.jam, but the effect is the same.

# user-config.jam
using mpi ;

# site-config.jam
using python : 2.7 : C:/Python27-x86 ;
using msvc : 10.0 : cl.exe : <compileflags>-D_SECURE_SCL=0 <compileflags>-D_CRT_NONSTDC_NO_DEPRECATE <compileflags>-D_CRT_SECURE_NO_WARNINGS <compileflags>-D_SCL_SECURE_NO_WARNINGS ;

[Vladimir Prus]

Thanks. Can you then run bjam with a couple of extra options:

--with-python --debug-building

and attach the complete output as well?

[Katie Chan]

Debugging build log

[Katie Chan]

Well, the program doesn't occur when building python. It turns out to happens when specifying python installation explicitly when building mpi. The attached zip file contain explicit-mpi.log where python was specified explicitly, and implicit-mpi.log where it wasn't.

[anonymous]

Possible fix

[Vladimir Prus]

Could you try the attached patch?

[Katie Chan]

Nope, doesn't work.

[Vladimir Prus]

Are you sure you get exactly the same error? For me, if I apply the patch I get a different error -- specifically that Python's extension to support MPI (called mpi.so on my system) is being installed to stage/mpi.so twice -- once as release version and another as debug. That issue is relatively long-standing -- maintained of Boost.MPI have not, to my knowledge, decided whether only one variant should be installed, or whether some of the variants should be renamed.

However, before we go there, can you confirm that the original error is gone, and you get a different one? If possible, please attach the text of the new message.

[Vladimir Prus]

I have checked in the fix I've attached before in r65639.