[Filesystem] Intel 7.1/Linux failures
Does anyone have anything to say on this one (from http://tinyurl.com/5jnv6) Compiler output []: /boost/head-regression/boost/libs/filesystem/build/../src/operations_posix_windows.cpp(122): error: the global scope has no "readdir64" if ( (dp = ::readdir( handle )) == 0 ) ^ /boost/head-regression/boost/libs/filesystem/build/../src/operations_posix_windows.cpp(313): error: incomplete type is not allowed struct stat path_stat; ^ /boost/head-regression/boost/libs/filesystem/build/../src/operations_posix_windows.cpp(314): error: the global scope has no "stat64" if(::stat( ph.string().c_str(), &path_stat ) != 0) ^ /boost/head-regression/boost/libs/filesystem/build/../src/operations_posix_windows.cpp(339): error: incomplete type is not allowed struct stat lcl_stat; ^ [...] ? Should I mark the library as unusable in this configuration? -- Aleksey Gurtovoy MetaCommunications Engineering
At 09:21 AM 9/19/2004, Aleksey Gurtovoy wrote:
Does anyone have anything to say on this one (from http://tinyurl.com/5jnv6)
Compiler output []:
/boost/head-regression/boost/libs/filesystem/build/../src/operations_posix_w indows.cpp(122): error: the global scope has no "readdir64" if ( (dp = ::readdir( handle )) == 0 ) ^
/boost/head-regression/boost/libs/filesystem/build/../src/operations_posix_w indows.cpp(313): error: incomplete type is not allowed struct stat path_stat; ^
/boost/head-regression/boost/libs/filesystem/build/../src/operations_posix_w indows.cpp(314): error: the global scope has no "stat64" if(::stat( ph.string().c_str(), &path_stat ) != 0) ^
/boost/head-regression/boost/libs/filesystem/build/../src/operations_posix_w indows.cpp(339): error: incomplete type is not allowed struct stat lcl_stat; ^ [...]
?
Should I mark the library as unusable in this configuration?
I would say yes, mark as unusable, unless someone with access to Intel 7.1 on Linux wants to fool with it. I think what is happening is that large file system support is somehow faulty for this configuration. My guess is that this is an Intel rather than Boost problem. Note that it works fine for later Intel versions. --Beman
Aleksey Gurtovoy wrote:
Does anyone have anything to say on this one (from http://tinyurl.com/5jnv6)
/boost/head-regression/boost/libs/filesystem/build/../src/operations_posix_windows.cpp(313): error: incomplete type is not allowed struct stat path_stat;
This one could be caused by a missing #include <sys/types.h> Regards, m
At 11:08 AM 9/19/2004, Martin Wille wrote:
Aleksey Gurtovoy wrote:
Does anyone have anything to say on this one (from http://tinyurl.com/5jnv6)
/boost/head-regression/boost/libs/filesystem/build/../src/operations_posix_w indows.cpp(313): error: incomplete type is not allowed
struct stat path_stat;
This one could be caused by a missing #include <sys/types.h>
I've checked in a change to see if that is the problem. Thanks, --Beman
At 03:50 PM 9/19/2004, Beman Dawes wrote:
At 11:08 AM 9/19/2004, Martin Wille wrote:
Aleksey Gurtovoy wrote:
Does anyone have anything to say on this one (from http://tinyurl.com/5jnv6)
/boost/head-regression/boost/libs/filesystem/build/../src/operations_pos ix _w indows.cpp(313): error: incomplete type is not allowed
struct stat path_stat;
This one could be caused by a missing #include <sys/types.h>
I've checked in a change to see if that is the problem.
That change doesn't to have cleared the Intel 7.l/Linux failures, although it does seem to have fixed the GCC 2.93 problem. I'm on my way out-of-town for a week and won't be able to do any more on this, but if you want to try possible fixes, feel free to experiment. But given that Intel 8.0 works, I don't see 7.1 failures as a high priority problem. Thanks, --Beman
Beman Dawes writes:
At 03:50 PM 9/19/2004, Beman Dawes wrote:
At 11:08 AM 9/19/2004, Martin Wille wrote:
Aleksey Gurtovoy wrote:
Does anyone have anything to say on this one (from http://tinyurl.com/5jnv6)
>/boost/head-regression/boost/libs/filesystem/build/../src/operations_pos ix
_w
indows.cpp(313): error: incomplete type is not allowed
struct stat path_stat;
This one could be caused by a missing #include <sys/types.h>
I've checked in a change to see if that is the problem.
That change doesn't to have cleared the Intel 7.l/Linux failures, although it does seem to have fixed the GCC 2.93 problem.
I'm on my way out-of-town for a week and won't be able to do any more on this, but if you want to try possible fixes, feel free to experiment. But given that Intel 8.0 works, I don't see 7.1 failures as a high priority problem.
Same here. Marked the library as unusable with Intel 7.l/Linux. -- Aleksey Gurtovoy MetaCommunications Engineering
Beman Dawes wrote:
At 03:50 PM 9/19/2004, Beman Dawes wrote:
At 11:08 AM 9/19/2004, Martin Wille wrote:
Aleksey Gurtovoy wrote:
Does anyone have anything to say on this one (from http://tinyurl.com/5jnv6)
/boost/head-regression/boost/libs/filesystem/build/../src/operations_pos ix _w
indows.cpp(313): error: incomplete type is not allowed
struct stat path_stat;
This one could be caused by a missing #include <sys/types.h>
I've checked in a change to see if that is the problem.
That change doesn't to have cleared the Intel 7.l/Linux failures, although it does seem to have fixed the GCC 2.93 problem.
I'm on my way out-of-town for a week and won't be able to do any more on this, but if you want to try possible fixes, feel free to experiment. But given that Intel 8.0 works, I don't see 7.1 failures as a high priority problem.
There are two problems: 1. POSIX feature flags get set *after* the first #include of a POSIX header. This likely will confuse the POSIX feature flag system. This probably also explains why the code later #defines flags internally used by that system. 2. The feature flag system special-cases gcc. This makes things rather ugly for us because the type returned by readdir() changes with the compiler: dirent * for gcc, dirent64 * for icc. Those types, however, have the same layout if 64 bit support was enabled by #defining _FILE_OFFSET_BITS to 64 before #including a POSIX header. Regards, m
At 02:51 AM 9/21/2004, Martin Wille wrote:
... There are two problems:
1. POSIX feature flags get set *after* the first #include of a POSIX header. This likely will confuse the POSIX feature flag system. This probably also explains why the code later #defines flags internally used by that system.
2. The feature flag system special-cases gcc. This makes things rather ugly for us because the type returned by readdir() changes with the compiler: dirent * for gcc, dirent64 * for icc. Those types, however, have the same layout if 64 bit support was enabled by #defining _FILE_OFFSET_BITS to 64 before #including a POSIX header.
I'm not sure that analysis is correct since (1) it is only affecting one particular version of one compiler, rather than all POSIX compilers, and (2) other than some Boost headers, which presumably don't include POSIX headers, the define is give before inclusion other headers. It any case, please try moving the define to the first line of the file, and let me know if that changes the results. Thanks, --Beman
Beman Dawes wrote:
At 02:51 AM 9/21/2004, Martin Wille wrote:
... There are two problems:
1. POSIX feature flags get set *after* the first #include of a POSIX header. This likely will confuse the POSIX feature flag system. This probably also explains why the code later #defines flags internally used by that system.
2. The feature flag system special-cases gcc. This makes things rather ugly for us because the type returned by readdir() changes with the compiler: dirent * for gcc, dirent64 * for icc. Those types, however, have the same layout if 64 bit support was enabled by #defining _FILE_OFFSET_BITS to 64 before #including a POSIX header.
I'm not sure that analysis is correct since (1) it is only affecting one particular version of one compiler, rather than all POSIX compilers, and
It could simply be luck that the code works correctly on other systems. However, it seems the 64 bit flags are not defined by POSIX. Nevertheless, the feature selection of glibc behaves similar to the POSIX rules, according to <features.h>
(2) other than some Boost headers, which presumably don't include POSIX headers, the define is give before inclusion other headers.
Boost.Config #includes <unistd.h>, if I recall correctly. So, basically every Boost header does #include POSIX headers. IEEE Std 1003.1-2001 says: "In the compilation of an application that #defines a feature test macro specified by IEEE Std 1003.1-2001, no header defined by IEEE Std 1003.1-2001 shall be included prior to the definition of the feature test macro. This restriction also applies to any implementation-provided header in which these feature test macros are used. If the definition of the macro does not precede the #include, the result is undefined."
It any case, please try moving the define to the first line of the file, and let me know if that changes the results.
No, that doesn't work. I described the symptoms under point 2 in my former posting. I guess we could try to use dirent64 instead of the dirent type for icc. Regards, m
participants (3)
-
Aleksey Gurtovoy -
Beman Dawes -
Martin Wille