Как проверить версию Linux с Autoconf? - PullRequest
Новая
       2

Как проверить версию Linux с Autoconf?

1 голос
/ 06 июня 2010

Моя программа требует как минимум Linux 2.6.26 (я использую timerfd и некоторые другие специфичные для Linux функции).

У меня есть общее представление о том, как написать этот макрос, но у меня недостаточно знаний о написании тестовых макросов для Autoconf. Алгоритм:

  1. Запустите "uname --release" и сохраните вывод
  2. Разобрать вывод и вычесть номер версии Linux (MAJOR.MINOR.MICRO)
  3. Сравнить версию

Я не знаю, как запустить команду, сохранить вывод и разобрать его.

Может быть, такой макрос уже существует и доступен (я не нашел)?

Ответы [ 4 ]

6 голосов
/ 06 июня 2010

Я думаю, что вам лучше определить конкретные функции, которые вам нужны, используя AC_CHECK_FUNC, а не конкретную версию ядра. Это также предотвратит поломку, если в будущем вы столкнетесь с кросс-компиляцией

2 голосов
/ 10 июня 2010

Я бы посоветовал вам не проверять номер версии Linux, а определить, какой тип вам нужен или какой функции. Кто знает, может кто-то решит сделать бэкпорт timerfd_settime() на 2.4.х? Поэтому я думаю AC_CANONICAL_TARGET и AC_CHECK_LIB или подобные вам ваши друзья. Если вам нужно проверить аргументы функции или проверить поведение, вам лучше написать простую программу и использовать AC_LANG_CONFTEST([AC_LANG_PROGRAM(...)]) / AC_TRY_RUN для выполнения этой работы.

1 голос
/ 12 марта 2019

Существует макрос для шагов 2 (анализ) и 3 (сравнение) версии, ax_compare_version . Например: 

linux_version=$(uname --release)
AX_COMPARE_VERSION($linux_version, [eq3], [2.6.26],
    [AC_MSG_NOTICE([Ok])],
    [AC_MSG_ERROR([Bad Linux version])])

Здесь я использовал eq3, поэтому, если $linux_version содержит дополнительные строки, такие как -amd64, сравнение все равно будет успешным. Существует множество операторов сравнения.

1 голос
/ 06 июня 2010

Не вдаваясь в подробности и правильно пишите макросы autoconf (что было бы предпочтительнее в любом случае), не забывайте, что configure.ac - это, по сути, сценарий оболочки, предварительно обработанный m4.Таким образом, вы можете писать команды оболочки напрямую. 

 # prev. part of configure.ac
 if test `uname -r |cut -d. -f1` -lt 2 then; echo "major v. error"; exit 1; fi
 if test `uname -r |cut -d. -f2` -lt 6 then; echo "minor v. error"; exit 1; fi
 if test `uname -r |cut -d. -f3` -lt 26 then; echo "micro error"; exit 1; fi
 # ...

Это просто идея, если вы хотите сделать это, избегая написания макросов для autoconf.Этот выбор не является хорошим, но должен работать ...

Лучший способ - это уже предложенный: вы должны проверить наличие функций;скажем, в будущем ядре timerfd больше не доступен ... или каким-то образом изменен ваш код не работает ... вы не поймаете его, так как тестируете на версию.

edit

Как говорит пользователь foof в комментариях (другими словами), это наивный способ проверить наличие файла major.minor.micro.Например, 3.5.1 потерпит неудачу из-за того, что 5 является lt 6, но 3.5.1 идет после 2.6.26, поэтому (вероятно) это следует принять.Существует много приемов, которые можно использовать для преобразования xyz в представление, которое переводит каждую версию в «естественный» порядок.Например, если мы ожидаем, что x, y или z не будут больше 999, мы можем сделать что-то вроде умножения на 1000000 основных, 1000 младших и 1 микро: таким образом, вы можете сравнить результат с 2006026, как предложил Foof в комментариях).

...