strange filesystem dll behaviour
Hi, I'm having killer problems with the filesystem library. I'm compiling it with bjam "-sTOOLS=mingw", which seems to work just fine. All the tests pass etc. Then I wrote this simple program: #include <boost/filesystem/path.hpp> #include <iostream> using namespace std; using namespace boost::filesystem; int main() { try { path p("c:",native); } catch (exception & e) { cerr << "Error: " << e.what() << endl; return 1; } cerr << "Ok" << endl; return 0; } and compiled it with the Makefile: test: test.cpp Makefile g++ -g -I../boost/boost-compiled -I. -Wall -c test.cpp g++ -g -Wl,-enable-stdcall-fixup -Wl,-subsystem,console -Wall -o test.exe test.o libboost_filesystem-mgw-d-1_32.lib g++ -g -Wl,-enable-stdcall-fixup -Wl,-subsystem,console -Wall -o test-dll.exe test.o -L. -lboost_filesystem-mgw-d-1_3 (adjust for your paths, I copied the dlls and libs into the local dir Just To Be Sure). The output of running the two programs is as follows: paul@xyz ~/test $ ./test Ok paul@xyz ~/test $ ./test-dll.exe Error: boost::filesystem::path: invalid name "c:" in path: "c:" Why does it behave differently depending on the linkage? If I must use a .lib, what if it needs to be used in multiple .dlls of mine? Help? Thanks Paul
At 04:46 AM 1/19/2005, Paul wrote:
I'm having killer problems with the filesystem library.
I'm compiling it with bjam "-sTOOLS=mingw", which seems to work just fine. All the tests pass etc.
Then I wrote this simple program:...
I'm guessing BOOST_POSIX is getting defined, so you need to define BOOST_WINDOWS if you want the Windows rather POSIX behavior. See http://www.boost.org/libs/filesystem/doc/index.htm#Cgywin for discussion. There have been past reports of problems with Cygwin; perhaps mingw has similar issues. Please let me know what you find out. Thanks, --Beman
--- Beman Dawes <bdawes@acm.org> wrote:
At 04:46 AM 1/19/2005, Paul wrote:
I'm having killer problems with the filesystem library.
I'm compiling it with bjam "-sTOOLS=mingw", which seems to work just fine. All the tests pass etc.
Then I wrote this simple program:...
I'm guessing BOOST_POSIX is getting defined, so you need to define BOOST_WINDOWS if you want the Windows rather POSIX behavior. See http://www.boost.org/libs/filesystem/doc/index.htm#Cgywin for discussion.
There have been past reports of problems with Cygwin; perhaps mingw has similar issues.
I tried this by editing the mingw-tools.jam file and adding -DBOOST_WINDOWS (and also -D__WIN32__), its the same behaviour. Note I also set the define while compiling my own test cpp files. Plus, the BOOST_PLATFORM #define was originally (and correctly) set to WIN32. I printed it out just like the filesystem-test does it. The puzzling thing is it works fine with libboost_file....lib, but not with boost_file....dll yet it was compiled using the same bjam and the same toolset? ideas? thanks Paul Find local movie times and trailers on Yahoo! Movies. http://au.movies.yahoo.com
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? thanks, Paul
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?
More news, I have managed to hack a path around this problem by adding a function called 'get_native()' to the set of free functions in the filesystem library. It simply does 'return native;', so I can be sure both my program and the DLL library are talking about the same thing. Doesn't other parts of boost use similar tests against function addresses? I assume these would be broken too? This hack won't last forever, whats the correct way to solve this? Thanks Paul Find local movie times and trailers on Yahoo! Movies. http://au.movies.yahoo.com
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
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,
let me know if you have any problems reproducing the problem, i'm sure i can, and its a problem I'm worried about as i'm not sure where else in boost (or any other library) that this (broken?) technique is used. I'd rather not find out the hard way! thanks Paul
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@lists.boost.org [mailto:boost-users- bounces@lists.boost.org] On Behalf Of Beman Dawes Sent: Friday, January 21, 2005 7:18 AM To: boost-users@lists.boost.org; boost-users@lists.boost.org 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@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Hi, I thought you said this code was going away in "the next version" (see your response at the bottom). The code is still the same as in 1.32, and AFAIK, it will still suffer the same problem that I reported months ago. Namely, the test (checker == native) is NOT valid in a win32 DLL context, because the function pointers will have different addresses when they come from different DLL contexts! thanks Paul Beman Dawes wrote:
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@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
"Paul" <elegant_dice@yahoo.com> wrote in message news:43083E65.8040300@yahoo.com...
Hi,
I thought you said this code was going away in "the next version" (see your response at the bottom). The code is still the same as in 1.32, and AFAIK, it will still suffer the same problem that I reported months ago.
"Next version" as in next version of the filesystem library. That won't be available until Boost release 1.34. You can access it now via CVS, branch "i18n". Although subject to change, the code on that branch is relatively close to being done. The main thing that is left is to bring it into closer sync with the TR2 filesystem library proposal. Than shipped to the committee a couple of days ago, and should be available publicly on the WG21 web site in a week or so. --Beman
Beman Dawes wrote:
"Paul" <elegant_dice@yahoo.com> wrote in message news:43083E65.8040300@yahoo.com...
Hi,
I thought you said this code was going away in "the next version" (see your response at the bottom). The code is still the same as in 1.32, and AFAIK, it will still suffer the same problem that I reported months ago.
"Next version" as in next version of the filesystem library. That won't be available until Boost release 1.34.
Ok, great to hear the next version is close to being done, etc. However, would it be possible to at least add something to the documentation, or to add a test case to test for this problem, or to add a workaround, or post a patch for a workaround, or something? 1.34 is a long way away for a lot of us boost-users - 1.33 has only just arrived! Maybe this problem is a non-issue for everyone else here? Otherwise, fine, but it seems to me that theres been quite a few messages about people getting bitten by this filesystem-as-a-dll problem. Thats quite a few hours wasted, and a lot of frustration. so, can we do something for the interim? Thanks Paul
participants (3)
-
Beman Dawes -
Delfin Rojas -
Paul