如何解决有关大文件支持的兼容性问题？

Question

使用 off_t 作为一个函数（seek）的参数的库。 库和应用程序的编译方式不同，一个关闭大文件支持，另一个则关闭大文件支持。 这种情况会导致奇怪的运行时错误，因为两者对 off_t 的解释不同。 库如何在运行时检查应用程序的 off_t 大小？ 或者是否有其他解决方案，以便至少用户得到有意义的错误？

编辑：该库（用 c 和 autoconf 编程）已经存在，并且一些第三方应用程序使用它。 该库可以使用大文件支持进行编译（默认情况下通过 AC_SYS_LARGEFILE）。 它是多平台的，不仅仅是linux。 如何检测/防止已安装的应用程序因 LFS 的更改而损坏？

Answer 1

您可以向库添加一个 API 以返回 sizeof(off_t)，然后从客户端检查它。 或者，库可能要求每个应用程序提供 API 才能成功链接：

library.c:

size_t lib_get_off_t_size (void)
{
    return (sizeof(off_t));
}

client.c (init_function):

if (lib_get_off_t_size() != sizeof(off_t) {
    printf("Oh no!\n");
    exit();
}

如果库有 init 函数，那么您可以将检查放在那里，但客户端必须提供 API 来获取其 off_t 的大小，这通常不是库的工作方式。

Answer 2

在 Linux 上，当在打开大文件支持的情况下编译库时，off_t 定义为与 off64_t 相同。 因此，如果该库是使用大文件支持编译的库，您可以更改其接口以始终使用 off64_t 而不是 off_t （这可能需要 _LARGEFILE64_SOURCE code>) 并完全避免该问题。

您还可以检查应用程序是否正在使用大文件支持进行编译（通过查看 _FILE_OFFSET_BITS 是否未定义或 32）并拒绝编译（使用 # error）如果编译方式错误； 请参阅 /usr/include/features.h 和 功能测试宏。

Answer 3

如前所述，库将无法知道应用程序（作为库的客户端）是如何编译的，但反之亦然。 此外，我认为您正在谈论动态链接，因为静态链接在同一构建时间肯定不会有不同的开关。

与“Andrew Johnson”已经给出的答案类似，该库可以提供一种方法来确定它是否是使用大文件支持进行编译的。 知道此类构建时切换主要是通过 C 中的定义完成的，这可能看起来像这样：

//in library:
BOOL isLargeFileSupport (void)
{
#ifdef LARGE_FILE_SUPPORT
    return TRUE;
#else
    return FALSE;
#endif
}

然后应用程序知道如何处理该库报告的文件大小，或者在不兼容时拒绝工作：

//in application
BOOL bLibLFS = lib_isLargeFileSupport();
BOOL bAppLFS = FALSE;
#ifdef LARGE_FILE_SUPPORT
    bAppLFS = TRUE;
#endif

if (bLibLFS != bAppLFS)
    //incompatible versions, bail out
    exit(0);