|
Boost : |
From: Boris Gubenko (Boris.Gubenko_at_[hidden])
Date: 2006-06-09 13:41:56
On HP-UX, there is a bug in <sys/statvfs.h> header which results
in link error when building boost.filesystem library in 32-bit data
model (the default). Below is reproducer; setting _FILE_OFFSET_BITS
macro to 64 is necessary to unearth buggy code in the header:
bash-3.00$ cat statvfs_bug.cpp
#define _FILE_OFFSET_BITS 64
#include <sys/statvfs.h>
int main() {
statvfs((const char*)0, 0);
}
bash-3.00$ aCC statvfs_bug.cpp
ld: Unsatisfied symbol "statvfs(char const*,statvfs*)" in file statvfs_bug.o
1 errors.
bash-3.00$ aCC statvfs_bug.cpp +DD64
bash-3.00$
The bug will be fixed in HP-UX 11.31 where macro
_STATVFS_ACPP_PROBLEMS_FIXED will be defined to indicate a fix.
Module operations.cpp in the boost.filesystem library unconditionally
defines _FILE_OFFSET_BITS macro as 64 which triggers a bug when
building the library on HP-UX with BBv1. BBv2 build specifies +DD64
(64-bit data model) and is not affected by this problem.
The attached patch conditionalizes definition of _FILE_OFFSET_BITS
macro so it does not get defined as 64 on a HP-UX system with buggy
header when building in 32-bit data model. I tested it on a 11.23
system by building filesystem library with BBv1.
Can this patch be applied to both CVS HEAD and RC_1_34? Currently,
operations.cpp is identical in both HEAD and RC.
Thanks,
Boris Gubenko
cal-bear> diff -u operations.cpp.orig operations.cpp
--- operations.cpp.orig Fri Jun 9 09:40:54 2006
+++ operations.cpp Fri Jun 9 09:41:08 2006
@@ -16,7 +16,10 @@
#define _POSIX_PTHREAD_SEMANTICS // Sun readdir_r() needs this
+#if !(defined(__HP_aCC) && defined(_ILP32) && \
+ !defined(_STATVFS_ACPP_PROBLEMS_FIXED))
#define _FILE_OFFSET_BITS 64 // at worst, these defines may have no effect,
+#endif
#define __USE_FILE_OFFSET64 // but that is harmless on Windows and on POSIX
// 64-bit systems or on 32-bit systems which don't have files larger
// than can be represented by a traditional POSIX/UNIX off_t type.
cal-bear>
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk