Как решить эту проблему совместимости с поддержкой больших файлов?

Библиотека, использующая off_t в качестве параметра для одной функции (искать). Библиотека и приложение компилируются по-разному, одно с отключенной поддержкой больших файлов, другое с поддержкой больших файлов. Эта ситуация приводит к странным ошибкам во время выполнения, потому что обе интерпретируют off_t по-разному. Как библиотека может проверить во время выполнения размер off_t для приложения? Или есть другое решение, чтобы хотя бы пользователь получил осмысленную ошибку?

РЕДАКТИРОВАТЬ: библиотека (запрограммированная на c и с autoconf) уже существует, и некоторые сторонние приложения используют ее. Библиотека может быть скомпилирована с поддержкой больших файлов (по умолчанию через AC_SYS_LARGEFILE). Он мультиплатформенный, не только линукс. Как можно обнаружить/предотвратить поломку установленных приложений при изменении LFS?


c large-file-support
person Mnementh    schedule 29.10.2008    source источник

Ответы (3)


arrow_upward
2
arrow_downward

Вы можете добавить API в библиотеку, чтобы вернуть sizeof(off_t), а затем проверить его с клиента. В качестве альтернативы библиотека может потребовать, чтобы каждое приложение предоставило API для успешного связывания:

библиотека.с:

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();
}

Если в библиотеке есть функция инициализации, вы можете поставить галочку там, но тогда клиент должен будет предоставить API, чтобы получить размер своего off_t, что обычно не работает с библиотеками.

person Andrew Johnson    schedule 29.10.2008

arrow_upward
1
arrow_downward

В Linux, когда библиотека компилируется с включенной поддержкой больших файлов, off_t определяется так же, как off64_t. Таким образом, если библиотека скомпилирована с поддержкой больших файлов, вы можете изменить ее интерфейс, чтобы всегда использовать off64_t вместо off_t (для этого может потребоваться _LARGEFILE64_SOURCE) и полностью избежать проблемы.

Вы также можете проверить, компилируется ли приложение с поддержкой больших файлов или нет (увидев, что _FILE_OFFSET_BITS не определено или 32) и отказаться от компиляции (с #error), если оно компилируется неправильным образом; см. /usr/include/features.h и Макросы тестирования функций .

person CesarB    schedule 29.10.2008

arrow_upward
0
arrow_downward

Как было сказано ранее, библиотека не сможет узнать, как скомпилировано приложение (будучи клиентом библиотеки), но должно работать наоборот. Кроме того, я думаю, вы говорите о динамической компоновке, поскольку статическая компоновка, безусловно, не будет иметь разных переключателей в одно и то же время сборки.

Подобно уже данному ответу Эндрю Джонсона, библиотека может предоставить метод определения того, была ли она скомпилирована с поддержкой больших файлов или нет. Зная, что такие переключатели во время сборки в основном выполняются с помощью определений в 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);
person lImbus    schedule 29.10.2008