Opened 12 years ago
Closed 12 years ago
#4585 closed Bugs (fixed)
Filesystem library causes "Internal compiler error" in gcc 3.2.3.
Reported by: | Owned by: | Beman Dawes | |
---|---|---|---|
Milestone: | To Be Determined | Component: | filesystem |
Version: | Boost 1.44.0 | Severity: | Problem |
Keywords: | Cc: |
Description
When compiling Boost 1.44 with gcc 3.2.3, I get the following compile error in the filesystem library:
In file included from boost/boost/filesystem/v3/operations.hpp:25,
from boost/libs/filesystem/v3/src/operations.cpp:48:
boost/boost/filesystem/v3/path.hpp: In member function `const std::string
boost::filesystem3::path::file_string() const':
boost/boost/filesystem/v3/path.hpp:270: Internal compiler error in walk_tree,
at tree-inline.c:1326
I am using v2 of the filesystem library, not v3, but apparently v3 is built and included in libboost_filesystem even though I'm not using it.
I have no idea what this means or what's causing it, so I'm submitting it to you. Of course, I can work around it by modifying the Jamfile for filesystem. But it would be best if Boost just worked instead of forcing me to patch it for each system.
By the way, there is no chance that I will be able to use a newer gcc (than 3.2.3) anytime soon. This is code for a system where one of the parties supplying code is unwilling to reveal their source code or recompile it with a newer gcc.
Change History (2)
comment:1 by , 12 years ago
comment:2 by , 12 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Adding --disable-filesystem3 to the bjam command line will now disable building of V3 components.
--Beman
The V3 code is skipped if BOOST_NO_STD_WSTRING is defined, so an immediate workaround might be to rebuild with BOOST_NO_STD_WSTRING defined on the command line for whatever build engine you are using.
That may cause trouble with if you are actually relying on wstring support, so a longer term fix may be to add and additional macro. I'll give that a bit more thought, but in the meantime will leave this ticket open.
Thanks,
--Beman