I am having a big problem with BPL. When my extension module is compiled by bjam I think it is giving me bad code. I have a couple of functions in a C++ object that have almost the same signature, just slightly different names. I have a free function in the extension module for each of these that calls into the C++ object: MyObject* gObject; void DoSomethingToObject( int data ) { gObject->DoSomething( data ); } void SomethingElseToObject( int data ) { gObject->SomethingElse( data ); } gObject is a valid ptr. When this code executes, the gObject->DoSomething call actually calls gObject->SomethingElse and vise versa! So I went and changed names thinking maybe it was confused by similar names, that didn't help. I went as far as to add some bogus parameters to SomethingElse but even that did not work. It still happily calls the wrong function even though it was called with a different number of parameters. Now I don't trust the VS debugger at all, but as I step through the code everything seems to make sense. It's executing the code it's stepping through, it's not just displaying the wrong lines of code as it has done before for me. The 2 free functions that are called from Python get called fine. They're called by other C++ code not related to my module and it works fine. It's just the call into gObject that is bad from the wrapped free functions. If you ignore the fact that it's calling a function with different number of parameters and filling those in with garbage, even after the bogus call everything is working OK until an assertion of mine fails because the wrong function has been called at the wrong time. The gObject class looks just fine to me. Calling some other gObject member functions instead works fine. It's just the DoSomething and SomethingElse ones that are problematic. Thinking I probably had bad code elsewhere or something I moved the calls to these 2 free functions up so they're basically the first things called by the Python script, but I get the same result. Are there any known problems with compiling modules that would lead to something like this? I don't even know where to start. I guess I will have to try to come up with a small example demonstrating the problem. This is using boost 1.32 with vc-7_1. -jim