From: Delfin Rojas (drojas_at_[hidden])
Date: 2005-01-21 12:38:48
I just wanted to say that I have seen this problem too. I thought it was
something I was doing wrong. Normally, if I re-compile the dll it goes
away...
-delfin
> -----Original Message-----
> From: boost-users-bounces_at_[hidden] [mailto:boost-users-
> bounces_at_[hidden]] On Behalf Of Beman Dawes
> Sent: Friday, January 21, 2005 7:18 AM
> To: boost-users_at_[hidden]; boost-users_at_[hidden]
> Subject: Re: [Boost-users] strange filesystem dll behaviour
>
> 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
>
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> http://listarchives.boost.org/mailman/listinfo.cgi/boost-users