[filesystem] WIN32 Can not use drive name in directory
From my application there may come a time when I want to take a directory or file name from a user. In windows, there is a file selection box that can return the full path of a file that the user chooses. The full path in windows includes the drive name with a colon and then a backslash ( c:\ ). I can not seem to get the boost filesystem library to accept this as a valid
Hello, path even with the native checker. I also ran the test provided with boost for paths and it failed. The output is given below. $ bfs Platform is Windows initial_path().string() is "g:/boostfs" initial_path().native_file_string() is "g:\boostfs" d:/srcbuilds/boost_1_32_0/boost/test/minimal.hpp(129): exception "std::exception : boost::filesystem::path: invalid name "c:" in path: "c:/"" caught in function: 'int main(int, char**)' **** Testing aborted. **** 1 error detected It appears that the colon is in the list of invalid characters for a file and it is throwing things off. My version of Boost was compiled with MinGW under Windows XP SP2 using the command line bjam "-sTOOLS=mingw" stage If I am missing something please let me know. Thank you for your time, - Dave
"David Daeschler" <daveregs@rsaisp.com> wrote in message news:d72il3$ukb$1@sea.gmane.org...
Hello,
From my application there may come a time when I want to take a directory or file name from a user. In windows, there is a file selection box that can return the full path of a file that the user chooses. The full path in windows includes the drive name with a colon and then a backslash ( c:\ ). I can not seem to get the boost filesystem library to accept this as a valid path even with the native checker. I also ran the test provided with boost for paths and it failed. The output is given below.
$ bfs Platform is Windows initial_path().string() is "g:/boostfs" initial_path().native_file_string() is "g:\boostfs" d:/srcbuilds/boost_1_32_0/boost/test/minimal.hpp(129): exception "std::exception : boost::filesystem::path: invalid name "c:" in path: "c:/"" caught in function: 'int main(int, char**)'
**** Testing aborted. **** 1 error detected
It appears that the colon is in the list of invalid characters for a file and it is throwing things off.
My version of Boost was compiled with MinGW under Windows XP SP2 using the command line bjam "-sTOOLS=mingw" stage
If I am missing something please let me know.
I don't know what the problem is. Two different regression testers test mingw, and filesystem passes for both on all tests. If you haven't figured out what is wrong by tomorrow, let me know and I'll try to reproduce the problem. (The machine I'm writing this on isn't set up for development, so I can't test it right now.) --Beman
Hello Sir, Thank you for your reply. It looks like the tests all pass if I run them by using bjam and building them in their respective directories. However, if I compile the minimal.cpp file outside of the boost build environment (move the file somewhere else and build using make) the test fails. I think I may be missing required compiler defines when I compile my test program, but I can't figure out what these may be. As an example, I wrote a simple test program that currently fails under my configuration. bfs.cpp -- #include <boost/filesystem/path.hpp> #include <boost/filesystem/exception.hpp> namespace fs = boost::filesystem; #include <iostream> int main(int argc, char* argv[]) { try { fs::path p("c:\\3Com", fs::native); } catch (std::exception& e) { std::cout << e.what() << std::endl; } return 0; } Makefile -- CXX = g++ PROGRAM = bfs OBJECTS = $(PROGRAM).o INCDIRS = -I$(BOOSTROOT) CFLAGS = LIBDIRS = -L$(BOOSTROOT)/stage/lib LIBS = -lboost_filesystem-mgw-d-1_32 .SUFFIXES: .o .cpp .cpp.o : $(CXX) $(CFLAGS) $(INCDIRS) -c -o $@ $< all: $(PROGRAM) $(PROGRAM): $(OBJECTS) $(CXX) $(LIBDIRS) -o $(PROGRAM) $(OBJECTS) $(LIBS) clean: rm -f *.o *.exe The output of the program is - boost::filesystem::path: invalid name "c:\3Com" in path: "c:\3Com" "c:\3Com" is a valid directory on this machine. Thank you for your time, - Dave "Beman Dawes" <bdawes@acm.org> wrote in message news:d73bic$1jj$1@sea.gmane.org...
"David Daeschler" <daveregs@rsaisp.com> wrote in message news:d72il3$ukb$1@sea.gmane.org...
Hello,
From my application there may come a time when I want to take a directory or file name from a user. In windows, there is a file selection box that can return the full path of a file that the user chooses. The full path in windows includes the drive name with a colon and then a backslash ( c:\ ). I can not seem to get the boost filesystem library to accept this as a valid path even with the native checker. I also ran the test provided with boost for paths and it failed. The output is given below.
$ bfs Platform is Windows initial_path().string() is "g:/boostfs" initial_path().native_file_string() is "g:\boostfs" d:/srcbuilds/boost_1_32_0/boost/test/minimal.hpp(129): exception "std::exception : boost::filesystem::path: invalid name "c:" in path: "c:/"" caught in function: 'int main(int, char**)'
**** Testing aborted. **** 1 error detected
It appears that the colon is in the list of invalid characters for a file and it is throwing things off.
My version of Boost was compiled with MinGW under Windows XP SP2 using the command line bjam "-sTOOLS=mingw" stage
If I am missing something please let me know.
I don't know what the problem is. Two different regression testers test mingw, and filesystem passes for both on all tests.
If you haven't figured out what is wrong by tomorrow, let me know and I'll try to reproduce the problem. (The machine I'm writing this on isn't set up for development, so I can't test it right now.)
--Beman
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
"David Daeschler" <daveregs@rsaisp.com> writes:
Thank you for your reply. It looks like the tests all pass if I run them by using bjam and building them in their respective directories. However, if I compile the minimal.cpp file outside of the boost build environment (move the file somewhere else and build using make) the test fails.
I think I may be missing required compiler defines when I compile my test program, but I can't figure out what these may be.
As an example, I wrote a simple test program that currently fails under my configuration.
Try using bjam -a -odump.txt ...whatever-you-normally-pass-to-bjam... and then looking at dump.txt to see what options are being passed to the compiler. Then you can use them in your Makefile. HTH, -- Dave Abrahams Boost Consulting www.boost-consulting.com
Thanks to that output (-a -odump.txt ), I found something interesting when doing testing. When you run the tests on the boost filesystem, it builds a static library at: bin\boost\libs\filesystem\build\libboost_filesystem.lib\mingw\debug\libboost_filesystem-mgw-d-1_32.lib It then deletes the library when the tests are over. If I break the build right after it builds this test library and then link to that library from my test program, the program executes without an exception! For some reason the library that the tests are building is working, and the libraries that are built using [ jam "-sTOOLS=mingw" stage ] are not working! I am very confused now. Any help will be greatly appreciated. - Dave "David Abrahams" <dave@boost-consulting.com> wrote in message news:ud5ret36u.fsf@boost-consulting.com...
"David Daeschler" <daveregs@rsaisp.com> writes:
Thank you for your reply. It looks like the tests all pass if I run them by using bjam and building them in their respective directories. However, if I compile the minimal.cpp file outside of the boost build environment (move the file somewhere else and build using make) the test fails.
I think I may be missing required compiler defines when I compile my test program, but I can't figure out what these may be.
As an example, I wrote a simple test program that currently fails under my configuration.
Try using
bjam -a -odump.txt ...whatever-you-normally-pass-to-bjam...
and then looking at dump.txt to see what options are being passed to the compiler. Then you can use them in your Makefile.
HTH, -- Dave Abrahams Boost Consulting www.boost-consulting.com
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
"David Daeschler" <daveregs@rsaisp.com> writes:
Thanks to that output (-a -odump.txt ), I found something interesting when doing testing.
When you run the tests on the boost filesystem, it builds a static library at:
bin\boost\libs\filesystem\build\libboost_filesystem.lib\mingw\debug\libboost_filesystem-mgw-d-1_32.lib
It then deletes the library when the tests are over.
That's so that when we're doing the big regression tests we don't fill up testers' disks needlessly. You can pass --preserve-test-targets to bjam to suppress that behavior.
If I break the build right after it builds this test library and then link to that library from my test program, the program executes without an exception!
For some reason the library that the tests are building is working, and the libraries that are built using [ jam "-sTOOLS=mingw" stage ] are not working!
I am very confused now. Any help will be greatly appreciated.
I was suggesting that it has to do with the way you compiled your minimal.obj, and that you check that difference. However, since the library built for testing works with your minimal.obj it must be a difference in the way the library is being built for stage. So what is the difference in command-line options with bjam "-sTOOLS=mingw" stage vs. whatever you invoked to build/run the boost regression tests? Also, I guess you should consider whether there's just an outright bug in the test program, although it looks too simple to be wrong. -- Dave Abrahams Boost Consulting www.boost-consulting.com
Hello again,
You can pass --preserve-test-targets to bjam to suppress that behavior.
Ha, that's easier then hitting ctrl+c in the middle of the build, thanks :).
So what is the difference in command-line options vs. whatever you invoked to build/run the boost regression tests
To build the regression I go to lib/filesystem/test and run [ bjam "-sTOOLS=mingw" ] without the stage.
you should consider whether there's just an outright bug in the test program
I did, but it's basically the same line as the simple_ls program and compiling that and giving it a full path breaks too. ls sample: http://boost.org/libs/filesystem/example/simple_ls.cpp
fs::path( argv[1], fs::native )
Thank you for your time, - Dave "David Abrahams" <dave@boost-consulting.com> wrote in message news:uhdgpn58j.fsf@boost-consulting.com...
"David Daeschler" <daveregs@rsaisp.com> writes:
Thanks to that output (-a -odump.txt ), I found something interesting when doing testing.
When you run the tests on the boost filesystem, it builds a static library at:
bin\boost\libs\filesystem\build\libboost_filesystem.lib\mingw\debug\libboost_filesystem-mgw-d-1_32.lib
It then deletes the library when the tests are over.
That's so that when we're doing the big regression tests we don't fill up testers' disks needlessly. You can pass --preserve-test-targets to bjam to suppress that behavior.
If I break the build right after it builds this test library and then link to that library from my test program, the program executes without an exception!
For some reason the library that the tests are building is working, and the libraries that are built using [ jam "-sTOOLS=mingw" stage ] are not working!
I am very confused now. Any help will be greatly appreciated.
I was suggesting that it has to do with the way you compiled your minimal.obj, and that you check that difference. However, since the library built for testing works with your minimal.obj it must be a difference in the way the library is being built for stage. So what is the difference in command-line options with
bjam "-sTOOLS=mingw" stage
vs. whatever you invoked to build/run the boost regression tests?
Also, I guess you should consider whether there's just an outright bug in the test program, although it looks too simple to be wrong.
-- Dave Abrahams Boost Consulting www.boost-consulting.com
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
"David Daeschler" <daveregs@rsaisp.com> writes:
Hello again,
You can pass --preserve-test-targets to bjam to suppress that behavior.
Ha, that's easier then hitting ctrl+c in the middle of the build, thanks :).
So what is the difference in command-line options vs. whatever you invoked to build/run the boost regression tests
To build the regression I go to lib/filesystem/test and run [ bjam "-sTOOLS=mingw" ] without the stage.
Of course. I mean the command-line options issued to the compiler by bjam in each case. -- Dave Abrahams Boost Consulting www.boost-consulting.com
Good Morning (EST) Okay, I came in this morning and pulled off the build command lines from the test build and from the full build. This is what I came up with -- Full Build ..snip.. "g++" -c -Wall -ftemplate-depth-255 -g -O0 -fno-inline -mno-cygwin -I"bin\boost\libs\filesystem\build" -I"d:\srcbuilds\boost_1_32_0" -I "d:\srcbuilds\boost_1_32_0" -o "bin\boost\libs\filesystem\build\libboost_filesystem.lib\mingw\debug\runtime-link-static\path_posix_windows.obj" "d:\srcbuilds\boost_1_32_0\libs\filesystem\build\../src/path_posix_windows.cpp" ..snip.. "d:\MinGW\bin\ar.exe" ru "bin\boost\libs\filesystem\build\libboost_filesystem.lib\mingw\debug\runtime-link-static\libboost_filesystem-mgw-sd-1_32.lib" "bin\boost\libs\filesystem\build\libboost_filesystem.lib\mingw\debug\runtime-link-static\exception.obj" "bin\boost\libs\filesystem\build\libboost_filesystem.lib\mingw\debug\runtime-link-static\operations_posix_windows.obj" "bin\boost\libs\filesystem\build\libboost_filesystem.lib\mingw\debug\runtime-link-static\path_posix_windows.obj" "bin\boost\libs\filesystem\build\libboost_filesystem.lib\mingw\debug\runtime-link-static\convenience.obj" ..snip.. -- Test Build ..snip.. "g++" -c -Wall -ftemplate-depth-255 -g -O0 -fno-inline -mno-cygwin -I"..\..\..\bin\boost\libs\filesystem\build" -I"d:\srcbuilds\boost_1_32_0" -I "d:\srcbuilds\boost_1_32_0" -o "..\..\..\bin\boost\libs\filesystem\build\libboost_filesystem.lib\mingw\debug\path_posix_windows.obj" "d:\srcbuilds\boost_1_32_0\libs\filesystem\build\../src/path_posix_windows.cpp" ..snip.. "d:\MinGW\bin\ar.exe" ru "..\..\..\bin\boost\libs\filesystem\build\libboost_filesystem.lib\mingw\debug\libboost_filesystem-mgw-d-1_32.lib" "..\..\..\bin\boost\libs\filesystem\build\libboost_filesystem.lib\mingw\debug\exception.obj" "..\..\..\bin\boost\libs\filesystem\build\libboost_filesystem.lib\mingw\debug\operations_posix_windows.obj" "..\..\..\bin\boost\libs\filesystem\build\libboost_filesystem.lib\mingw\debug\path_posix_windows.obj" "..\..\..\bin\boost\libs\filesystem\build\libboost_filesystem.lib\mingw\debug\convenience.obj" ..snip.. As you can see the commands are the same as far as parameters that would affect the build. So the insight came when I linked to the built filesystem static library instead of the DLL. It appears that when I statically link the filesystem lib in it works fine, but when I let g++ dynamically link to the DLL (using -l ) it tells me that c:\ is an invalid path. "David Abrahams" <dave@boost-consulting.com> wrote in message news:u3bs9iq0k.fsf@boost-consulting.com...
"David Daeschler" <daveregs@rsaisp.com> writes:
Hello again,
You can pass --preserve-test-targets to bjam to suppress that behavior.
Ha, that's easier then hitting ctrl+c in the middle of the build, thanks :).
So what is the difference in command-line options vs. whatever you invoked to build/run the boost regression tests
To build the regression I go to lib/filesystem/test and run [ bjam "-sTOOLS=mingw" ] without the stage.
Of course. I mean the command-line options issued to the compiler by bjam in each case.
-- Dave Abrahams Boost Consulting www.boost-consulting.com
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
participants (3)
-
Beman Dawes -
David Abrahams -
David Daeschler