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.