At 01:12 AM 1/20/2005, Paul wrote:
I looked deeper into the problem, and hacked up boost a little to find out that the problem is the following check:
if ( (checker == no_check || checker == native) && src.size() >= 2 ) at path_posix_windows.cpp:243
specifically checker==native.
I had constructed path with boost::filesystem::native, but when I hacked it up to do the following:
# ifdef BOOST_WINDOWS std::stringstream ss; ss << "checker=" << reinterpret_cast<unsigned long>(checker) << std::endl << "native=" << reinterpret_cast<unsigned long>(native) << std::endl; boost::throw_exception( filesystem_error( "boost::filesystem::path", ss.str() ));
if ( (checker == no_check || checker == native) && src.size() >= 2 )
I got the following results from calling the line: boost::filesystem::path p(s,boost::filesystem::native);
linking to libboost_filesystem-mgw-d-1_32.lib: checker=4201048 native=4201048
linking to boost_filesystem-mgw-d-1_32.dll: checker=4263776 native=1649966248
so, it appears that testing the checker using the address of a function is unreliable in a DLL context? Have I compiled my program/library incorrectly? I am not too familiar with DLL details etc, can someone else please shed some light on this?
I'm not a DLL expert either, but it certainly looks like there is some problem with address of functions across DLL boundaries. This code will be going away in the next version of the library, so I'm not sure if it is worth putting a lot of effort into fixing it. But I'll try to reproduce the problem here. If it does reproduce, it shouldn't be too hard to come up with an interim fix. Thanks for the report, --Beman