[filesystem] large file support detection broken on Solaris (possibly others)
The file "operations_posix_windows.cpp" in the filesystem library defines the macro _FILE_OFFSET_BITS=64 in an attempt to enable large file support on POSIX platforms. Unfortunately, this definition comes too late for it to work properly on Solaris, so Boost.Filesystem incorrectly reports that large file support is unavailable (cf. http://tinyurl.com/44jvy). The _FILE_OFFSET_BITS macro definition needs to happen before the inclusion of <sys/types.h>, but this system header is being pulled in courtesy of <boost/config.hpp> which is included by <boost/filesystem/config.hpp>. I'm attaching the output of g++ -H on this file which lists header files as they are included, along with a nesting depth so you can see what is going on. Can this macro definition just be moved before any other includes? I think it should be harmless on any non-POSIX platform. I think defining it before ANY header is included or on the compiler command-line is the only way for to make this work reliably. -- Caleb Epstein caleb dot epstein at gmail dot com
On Mon, 14 Mar 2005 08:57:25 -0500, Caleb Epstein <caleb.epstein@gmail.com> wrote:
The file "operations_posix_windows.cpp" in the filesystem library defines the macro _FILE_OFFSET_BITS=64 in an attempt to enable large file support on POSIX platforms. Unfortunately, this definition comes too late for it to work properly on Solaris, so Boost.Filesystem incorrectly reports that large file support is unavailable (cf. http://tinyurl.com/44jvy).
The _FILE_OFFSET_BITS macro definition needs to happen before the inclusion of <sys/types.h>, but this system header is being pulled in courtesy of <boost/config.hpp> which is included by <boost/filesystem/config.hpp>. I'm attaching the output of g++ -H on this file which lists header files as they are included, along with a nesting depth so you can see what is going on.
Can this macro definition just be moved before any other includes? I think it should be harmless on any non-POSIX platform. I think defining it before ANY header is included or on the compiler command-line is the only way for to make this work reliably.
I've received no reply to this bug report, so I'm following up and CC'ing Beman. -- Caleb Epstein caleb dot epstein at gmail dot com
On Mon, 21 Mar 2005 10:32:02 -0500, Caleb Epstein <caleb.epstein@gmail.com> wrote:
On Mon, 14 Mar 2005 08:57:25 -0500, Caleb Epstein <caleb.epstein@gmail.com> wrote:
The file "operations_posix_windows.cpp" in the filesystem library defines the macro _FILE_OFFSET_BITS=64 in an attempt to enable large file support on POSIX platforms. Unfortunately, this definition comes too late for it to work properly on Solaris, so Boost.Filesystem incorrectly reports that large file support is unavailable (cf. http://tinyurl.com/44jvy).
The _FILE_OFFSET_BITS macro definition needs to happen before the inclusion of <sys/types.h>, but this system header is being pulled in courtesy of <boost/config.hpp> which is included by <boost/filesystem/config.hpp>. I'm attaching the output of g++ -H on this file which lists header files as they are included, along with a nesting depth so you can see what is going on.
Can this macro definition just be moved before any other includes? I think it should be harmless on any non-POSIX platform. I think defining it before ANY header is included or on the compiler command-line is the only way for to make this work reliably.
I've received no reply to this bug report, so I'm following up and CC'ing Beman.
Another week passes and no reply. Anyone home? This should be a really simple fix. -- Caleb Epstein caleb dot epstein at gmail dot com
At 04:49 PM 3/28/2005, Caleb Epstein wrote:
On Mon, 21 Mar 2005 10:32:02 -0500, Caleb Epstein <caleb.epstein@gmail.com> wrote:
On Mon, 14 Mar 2005 08:57:25 -0500, Caleb Epstein <caleb.epstein@gmail.com> wrote:
The file "operations_posix_windows.cpp" in the filesystem library defines the macro _FILE_OFFSET_BITS=64 in an attempt to enable large file support on POSIX platforms. Unfortunately, this definition comes too late for it to work properly on Solaris, so Boost.Filesystem incorrectly reports that large file support is unavailable (cf. http://tinyurl.com/44jvy).
The _FILE_OFFSET_BITS macro definition needs to happen before the inclusion of <sys/types.h>, but this system header is being pulled in courtesy of <boost/config.hpp> which is included by <boost/filesystem/config.hpp>. I'm attaching the output of g++ -H on this file which lists header files as they are included, along with a nesting depth so you can see what is going on.
Can this macro definition just be moved before any other includes? I think it should be harmless on any non-POSIX platform. I think defining it before ANY header is included or on the compiler command-line is the only way for to make this work reliably.
I've received no reply to this bug report, so I'm following up and CC'ing Beman.
Another week passes and no reply. Anyone home? This should be a really simple fix.
OK, changed in CVS for both the main trunk and the i18n branch. The slowdown is simply that 99% of the filesystem effort is currently going into the i18n effort. --Beman
On Thu, 31 Mar 2005 09:32:25 -0500, Beman Dawes <bdawes@acm.org> wrote:
OK, changed in CVS for both the main trunk and the i18n branch.
The slowdown is simply that 99% of the filesystem effort is currently going into the i18n effort.
Thanks. I understand the priority. I was just concerned that my report was being ignored not delayed. -- Caleb Epstein caleb dot epstein at gmail dot com
On Mar 31, 2005 10:32 AM, Beman Dawes <bdawes@acm.org> wrote:
OK, changed in CVS for both the main trunk and the i18n branch.
OK this is still not fixed. The macro should be _FILE_OFFSET_BITS, not _USE_FILE_OFFSET_BITS. -- Caleb Epstein caleb dot epstein at gmail dot com
"Caleb Epstein" <caleb.epstein@gmail.com> wrote in message news:989aceac050406061276d82b35@mail.gmail.com...
On Mar 31, 2005 10:32 AM, Beman Dawes <bdawes@acm.org> wrote:
OK, changed in CVS for both the main trunk and the i18n branch.
OK this is still not fixed. The macro should be _FILE_OFFSET_BITS, not _USE_FILE_OFFSET_BITS.
Grrr... Sorry, should be fixed now. If there are further problems, just go ahead and fix CVS yourself. Thanks, --Beman
participants (3)
-
Beman Dawes -
Caleb Epstein