Я надеюсь, что какой-нибудь упорный Linux сможет мне ответить, как мне писать переносимый (POSIX) код при работе с функциями времени.
Некоторые потоки SO предлагают , что включение ctime будет правильным решением при написании кода на C ++, тогда как вы все равно включите time.h для кода на C. Однако они оба определяют одну и ту же функцию, хотя и в другом пространстве имен. Технически вы должны быть в состоянии указать оба.
В одном сообщении SO предлагалось ИЗБЕГАТЬ, используя основанный на sys / *, включает в себя все ..
.. в то время как этот поток подразумевает, что sys / time.h должен быть включен до включения sys / resources.h, в частности для платформ на основе BSD.
В этом сообщении говорится, что включение sys / time.h улучшает переносимость. Я полагаю, что автор думает, что он позволяет вам связывать больше сторонних библиотек, которые используют определенные функции, такие как gettimeofday .. однако ..
gettimeofday () был обескуражен , и теперь в настоящее время имеет статус устарел , поэтому я должен использовать clock_gettime () вместо этого. Это clock_gettime () определено в time.h, см. https://linux.die.net/man/3/clock_gettime..
.. если установить и связать с libavutil (например, как часть ffmpeg-dev), становится ясно, что time.h был создан, чтобы сводить людей с ума . У Ffmpeg (и некоторых других библиотек) есть свое время time.h и даже timeb.h. Оказывается, если ЛЮБОЙ .c или .cpp где-нибудь в вашем стеке сборки когда-либо включает a time.h, с включенным путем, содержащим несколько допустимых записей (, включая тот, что для ffmpeg ) , это может относиться к неправильному, и объявления просто заменяются. @ FFmpeg, похоже, что для устранения проблемы достаточно некрасивого хака . Мне еще не так повезло. Кроме того, Php-izing всех источников не звучит как решение вообще.
Другой файл time.h существует в моей системе в файле usr / include / i386-linux-gnu / bits, так что это также не явление только для ffmpeg. Простое обращение к usr / include / i386-linux-gnu как пути включения, таким образом, становится смертельно опасным, что странно при обращении к системным включениям.
Я переписал свои сценарии CMake, стараясь использовать выделенные спецификации папок для большинства целей. Я попытался включить все виды перестановок time.h / ctime и sys / time.h в предварительно скомпилированный заголовок, который упоминается в кодовой базе. Я по-прежнему получаю сообщения об ошибках типа:
ошибка: поле "st_atim" имеет неполный тип "timespec", struct timespec st_atim;
ошибка: «время» не было объявлено
и т.д ..
Итак, для установки C ++, связывающей со многими сторонними зависимостями, как правильно убедиться, что все продолжает компилировать w.r.t. включая время. Должен ли я прикрепить time.h для системы к конкретной платформе, которую я компилирую? Должен ли я пройти все цели, которые, возможно, нуждаются во времени. Впереди танцующие слоны и конфетти.
Обновление: похоже, проблема связана с версией C ++, о чем было сказано в комментариях ниже. С тех пор я обновил gcc до 8.3.0 (с 5.4), и я разочаровался в поддержке старой совместимости c ++ ниже c ++ 11 на linux. После обновления и перестройки всех сторонних пакетов (включая ffmpeg) у меня больше нет проблемы, которую я описал, но это не значит, что она исправлена в том смысле, что она не может повториться для кого-то еще. Фактически, я думаю, что проблема в основном в том, как ffmpeg компилируется на старых компиляторах и без явного запроса c ++ 11, поэтому я оставляю его открытым.