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 | 216 | dnl Large File Support |
| 217 | 217 | AC_SYS_LARGEFILE |
| 218 | 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 | 220 | dnl Allow libtool to be silenced |
| 233 | 221 | AC_MSG_CHECKING([whether libtool should be silenced]) |