"Caleb Epstein" <caleb.epstein@gmail.com> wrote in message news:989aceac0512182000m4bffe9caq67b1a9d8697b0da0@mail.gmail.com...
***See: http://tinyurl.com/7pp9r
*These test results appear to pre-date line 69 below:
62 // BOOST_FILESYSTEM_STATUS_CACHE enables status_flags cache in 63 // dir_itr_increment. The config tests are placed here because some of the 64 // macros being tested come from dirent.h. 65 // 66 // TODO: "|| defined(__APPLE__)" compiles, but at runtime d_type is alwasy 0. Why? 67 // TODO: find out what macros enable dirent::d_type on various operating systems. 68 # if !defined(__CYGWIN__) && !defined(__osf__) \ 69 && !(defined(__sun) && defined(__GLIBCXX__)) \ 70 && (defined(BOOST_WINDOWS_API) \ 71 || defined(__USE_BSD) || defined(_DIRENT_HAVE_D_TYPE) \ 72 ) 73 # define BOOST_FILESYSTEM_STATUS_CACHE 74 # endif
So I expect Filesystem will compile properly on my Monday test run.
However I think the macro test should just be for defined(__sun), and not both __sun && __GLIBCXX__.
The lack of d_type in dirent is a C library issue, not a C++ library issue and as would affect any compiler on Solaris (e.g. SunPRO CC would hit this too).
My thinking was that there might be different C libraries available on Sun, and I was trying to use __GLIBCXX__ to differentiate. But you are probably right, so I'll make the change. In any can we are talking about an optimization, so turning it off does no functional harm (although it may impact performance). Thanks, --Beman