
Boost::filesystem::path is failing to create any paths. If always throws and exception stating invalid path. In the main function I call boost::filesystem::path::default_name_check( boost::filesystem::native ); boost::filesystem::initial_path(); The attempts to construct paths are in the pattern boost::filesystem::path(some_path_name); Specificly the error occurs here in constructing a path void path::m_path_append( const std::string & src, name_check checker ) { // convert backslash to forward slash if checker==native // allow system-specific-root if checker==no_check || checker==native assert( checker ); assert( src.size() == std::strlen( src.c_str() ) ); // no embedded 0 if ( src.size() == 0 ) return; std::string::const_iterator itr( src.begin() ); // [root-filesystem] # ifdef BOOST_WINDOWS if ( (checker == no_check || checker == native) && src.size() >= 2 ) // This fails { ... Since fore some reasion it seemed to be failing to get the native checker I tired this instead boost::filesystem::path(some_path_name,boost::filesystem::native); But the above test still fails. This seems to be related to the filesystem code being used in the main application and a DLL. I added this line to boost/config/user.hpp #define BOOST_FILESYSTEM_DYN_LINK So the library should be dynamicly linked and it being used in two places shouldn't be a problem. If I trace the function in a debugger all calls to the filesystem library look like this > FESMLibDebug.dll!boost::filesystem::path::default_name_check(bool (const std::basic_string<char,std::char_traits<char>,std::allocator<char> > &)* new_check=0x004573e2) > FESMLibDebug.dll!boost::filesystem::path::m_path_append(const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & src={...}, bool (const std::basic_string<char,std::char_traits<char>,std::allocator<char> > &)* checker=0x004573e2) So it doesn't look like im getting 2 copies of boostfile system. I previously was getting calls to $(APPNAME)!boost::filesystems and $(DLLNAME)!boost::filesystems. However, if I incluede the source files of the dll directly into the application the problem dissapears. Anyone know what I missed? This is with Visual C++ 2003 and Windows XP. Thanks Donald Johnson