-#if @GNULIB_FSEEK@ && @REPLACE_FSEEK@
-extern int rpl_fseek (FILE *fp, long offset, int whence);
-# undef fseek
-# if defined GNULIB_POSIXCHECK
-# define fseek(f,o,w) \
- (GL_LINK_WARNING ("fseek cannot handle files larger than 4 GB " \
- "on 32-bit platforms - " \
- "use fseeko function for handling of large files"), \
- rpl_fseek (f, o, w))
-# else
+/* Set up the following warnings, based on which modules are in use.
+ GNU Coding Standards discourage the use of fseek, since it imposes
+ an arbitrary limitation on some 32-bit hosts. Remember that the
+ fseek module depends on the fseeko module, so we only have three
+ cases to consider:
+
+ 1. The developer is not using either module. Issue a warning under
+ GNULIB_POSIXCHECK for both functions, to remind them that both
+ functions have bugs on some systems. _GL_NO_LARGE_FILES has no
+ impact on this warning.
+
+ 2. The developer is using both modules. They may be unaware of the
+ arbitrary limitations of fseek, so issue a warning under
+ GNULIB_POSIXCHECK. On the other hand, they may be using both
+ modules intentionally, so the developer can define
+ _GL_NO_LARGE_FILES in the compilation units where the use of fseek
+ is safe, to silence the warning.
+
+ 3. The developer is using the fseeko module, but not fseek. Gnulib
+ guarantees that fseek will still work around platform bugs in that
+ case, but we presume that the developer is aware of the pitfalls of
+ fseek and was trying to avoid it, so issue a warning even when
+ GNULIB_POSIXCHECK is undefined. Again, _GL_NO_LARGE_FILES can be
+ defined to silence the warning in particular compilation units.
+
+ Most gnulib clients that perform stream operations should fall into
+ category three. */
+
+#if @GNULIB_FSEEK@
+# if defined GNULIB_POSIXCHECK && !defined _GL_NO_LARGE_FILES
+# define _GL_FSEEK_WARN /* Category 2, above. */
+# undef fseek
+# endif
+# if @REPLACE_FSEEK@
+# undef fseek