If the system is too broken for AC_SYS_LARGEFILE to do the right thing, it is not our responsibility to fix it.
Unified · Split
| @@ -216,18 +216,6 @@ AC_CHECK_FUNCS([lrint]) · 215 unmodified lines | |||
| 216 | dnl Large File Support | 216 | dnl Large File Support |
| 217 | AC_SYS_LARGEFILE | 217 | AC_SYS_LARGEFILE |
| 218 | AC_FUNC_FSEEKO | 218 | AC_FUNC_FSEEKO |
| 219 | if test "$ac_cv_sys_file_offset_bits" = "64"; then | ||
| 220 | dnl This is either a 64-bit platform or a 32-bit platform | ||
| 221 | dnl that supports large files. | ||
| 222 | dnl There are to many broken glibc+kernel's out there that | ||
| 223 | dnl detect 64-bit off_t on 32-bit system and require | ||
| 224 | dnl _LARGEFILE_SOURCE to make fseeko() go into 64-bit mode. | ||
| 225 | dnl Force defining _LARGEFILE_SOURCE always. My assumption | ||
| 226 | dnl is its harmlessly ignored on 64-bit platforms and platforms | ||
| 227 | dnl that chose other solutions. | ||
| 228 | AC_MSG_NOTICE(Forcing _LARGEFILE_SOURCE to be safe since off_t is 64 bits) | ||
| 229 | AC_DEFINE(_LARGEFILE_SOURCE, 1) | ||
| 230 | fi | ||
| 231 | 219 | ||
| 232 | dnl Allow libtool to be silenced | 220 | dnl Allow libtool to be silenced |
| 233 | AC_MSG_CHECKING([whether libtool should be silenced]) | 221 | AC_MSG_CHECKING([whether libtool should be silenced]) |