Hi, here is another exasperating patch: If I compile the following code with MSVC (taken from number.h, I only added the extra qualification cln:: to illustrate the problem) namespace cln { inline _class_::_class_ (const unsigned long wert) { extern cl_private_thing cl_I_constructor_from_UL (uint32 wert); pointer = cln::cl_I_constructor_from_UL(wert); } } then I get the following error: ./include\cln/number.h(230) : error C2039: 'cl_I_constructor_from_UL' : is not a member of 'cln' and of course without the cln:: qualification I get linker errors for unresolved symbols because in cl_I_from_UL.cc the function is clearly defined inside the cln namespace. If I change the code to namespace cln { extern cl_private_thing cl_I_constructor_from_UL (uint32 wert); inline _class_::_class_ (const unsigned long wert) { pointer = cln::cl_I_constructor_from_UL(wert); } the errors disappear. I know that it is not desirable to move the extern declaration outside of the function body. But for MSVC this appears to be the only way to force the compiler to put it into the cln namespace. Therefore I would propose the following patch for MSVC only: // At the beginning of the file #ifdef _MSC_VER namespace cln { extern cl_private_thing cl_I_constructor_from_UL (uint32 wert); } #endif and the extra cln:: qualification as shown above. This is the solution with the smallest changes. But of course it would also be possible to create two versions of the inline functions and choose the right one with _MSC_VER. Please give me your opinions before I start any big edits. Thanks, Jan