Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2005-05-17 07:10:00

"Victor A. Wagner Jr." <vawjr_at_[hidden]> writes:

>>The problem is that one of the DLL dependencies of the .pyd file
>>(really a dynamically loaded DLL) that gets built is not in the PATH.
>>For VC8 there's a horrible problem finding MSVC80P.DLL. See
>> for more
>>information. I managed to get things to build by tracking down the
>>file and doing the build explicitly and doing
>> set
>> PATH=c:/windows/WinSxS/x86_Microsoft.VC80.DebugCRT_1fc8b3b9a1e18e3b_8.0.50215.4652_x-ww_a12cf373/;%PATH%
>>before firing up bjam. Of course, it will probably be in some other
>>subdirectory of C:\Windows\WinSxS on your machine.
> I
> added
> C:\WINDOWS\WinSxS\x86_Microsoft.VC80.DebugCRT_1fc8b3b9a1e18e3b_8.0.50215.4652_x-ww_a12cf373
> to my system path (so all users would access it) and it apparently made no
> difference in my tests
> yes, I looked fro the file and pasted the directory name in rather than
> using the one that worked on your machine, apparently it's in the same
> place on mine.

In that case I suggest you use "depends" on the .pyd file to track
down what other DLL dependencies it may have acquired, and put them in
the path. The way I actually verified this for myself was to download
a utility called NTFileMon that logs all filesystem activity. You can
filter out apps other than Python and actually watch the system
looking for all the DLL dependencies as it fails. If you don't want
to use bjam to launch it, all you need to do is do the environment
setup that bjam is doing and then invoke:

  python -c "import args_ext"


Dave Abrahams
Boost Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at