LINUX.ORG.RU

Ubuntu, версия компилятора (минимальное ядро)

 , , , ,


0

1

Лет 5 назад компилировал софтину для железке на ARM через arm-linux-gnueabi в режиме static. Она включала в себя openssl, который я тоже компил на этой же машине через arm-linux-gnueabi. До определенного времени все нормально работало, для периодических обновлений софтины использовал только установленный Ubuntu 14 или 16 (вроде даже на 20м тоже все было путем), после чего грохал систему за ненадобностью. Тулчейн использовал стандартный из репозитория Ubuntu (apt-get install gcc-arm-linux-gnueabi).

Вчера в очередной раз поднял Ubuntu 16, запилил openssl-1.0.2r, запилил софтину, закинул на железяку, а в ответ «FATAL: kernel too old». Оно и не удивительно, ядро там действительно старое:

3.0.21+ #1 PREEMPT Wed Feb 3 14:55:39 CST 2016 armv7l GNU/Linux
Но до сих пор все работало. Видимо один из компонентов Ubuntu теперь стал minimal-kernel-version выше чем 3.0.21. GLIBC 2.23 по-умолчанию. arm-linux-gnueabi-gcc ставится 5.4.0.

#ldd --version
ldd (Ubuntu GLIBC 2.23-0ubuntu11.2) 2.23
#arm-linux-gnueabi-gcc --version
arm-linux-gnueabi-gcc (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609

GLIBC до версии 2.24 как я понимаю с ядром 3.0.0 работает нормально.

Снес систему и на голую машину поставил максимальную версию, которая не выдала ошибку «kernel too old» на конечном устройсте, это arm-linux-gnueabi - gcc-linaro-6.5.0-2018.12-x86_64_arm-linux-gnueabi, взятый с releases.linaro.org - toolchain - binaries. Начиная с версии 7 получаю на конечном устройстве ошибку «kernel too old». Однако, openssl-1.0.2r на нем (toolchain 6.5.0) получается рабочим, но слишком жирным (около 6-8Мб в зависимости от параметров компиляции), против прежней версии удачно скомпилированной - около 3Мб. Для конечной железки это овердохрена. Условно «нормальный» размер бинарника выходит и с использованием gnueabi репозитория Ubuntu, но «kernel too old».

Собственно вопрос. Какой из компонентов мог обновиться и теперь имеет ограничения на минимальное ядро? И как это «проблему» побороть.

Поднимал Ubuntu от 14 до 20. Результат везде одинаков. В никсах хоть и не дуб, но знаний ровно на конкретные задачи, которые приходилось на них выполнять.

cd openssl-1.0.2r && ./Configure gcc -static -no-shared --prefix=/create_soft --cross-compile-prefix=arm-linux-gnueabi-

На голой системе

~# sudo apt-get install gcc-arm-linux-gnueabi
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
  binutils binutils-arm-linux-gnueabi cpp-5-arm-linux-gnueabi cpp-arm-linux-gnueabi gcc-5-arm-linux-gnueabi gcc-5-arm-linux-gnueabi-base gcc-5-cross-base libasan2-armel-cross libatomic1-armel-cross libc6-armel-cross
  libc6-dev-armel-cross libcc1-0 libgcc-5-dev-armel-cross libgcc1-armel-cross libgomp1-armel-cross libisl15 libmpc3 libmpfr4 libstdc++6-armel-cross libubsan0-armel-cross linux-libc-dev-armel-cross
Suggested packages:
  binutils-doc gcc-5-locales cpp-doc gcc-5-multilib-arm-linux-gnueabi gcc-5-doc libgcc1-dbg-armel-cross libgomp1-dbg-armel-cross libitm1-dbg-armel-cross libatomic1-dbg-armel-cross libasan2-dbg-armel-cross liblsan0-dbg-armel-cross
  libtsan0-dbg-armel-cross libubsan0-dbg-armel-cross libcilkrts5-dbg-armel-cross libmpx0-dbg-armel-cross libquadmath0-dbg-armel-cross make manpages-dev autoconf automake libtool flex bison gdb-arm-linux-gnueabi gcc-doc
The following NEW packages will be installed:
  binutils binutils-arm-linux-gnueabi cpp-5-arm-linux-gnueabi cpp-arm-linux-gnueabi gcc-5-arm-linux-gnueabi gcc-5-arm-linux-gnueabi-base gcc-5-cross-base gcc-arm-linux-gnueabi libasan2-armel-cross libatomic1-armel-cross
  libc6-armel-cross libc6-dev-armel-cross libcc1-0 libgcc-5-dev-armel-cross libgcc1-armel-cross libgomp1-armel-cross libisl15 libmpc3 libmpfr4 libstdc++6-armel-cross libubsan0-armel-cross linux-libc-dev-armel-cross
0 upgraded, 22 newly installed, 0 to remove and 1 not upgraded.
Need to get 22.2 MB of archives.
After this operation, 78.4 MB of additional disk space will be used.
Do you want to continue? [Y/n]

......................
Processing triggers for libc-bin (2.23-0ubuntu11.2) ...
Setting up libmpfr4:amd64 (3.1.4-1) ...
Setting up libmpc3:amd64 (1.0.3-1) ...
Setting up binutils (2.26.1-1ubuntu1~16.04.8) ...
Setting up gcc-5-arm-linux-gnueabi-base:amd64 (5.4.0-6ubuntu1~16.04.9cross1) ...
Setting up libisl15:amd64 (0.16.1-1) ...
Setting up cpp-5-arm-linux-gnueabi (5.4.0-6ubuntu1~16.04.9cross1) ...
Setting up cpp-arm-linux-gnueabi (4:5.3.1-1ubuntu1) ...
Setting up libcc1-0:amd64 (5.4.0-6ubuntu1~16.04.12) ...
Setting up binutils-arm-linux-gnueabi (2.26.1-1ubuntu1~16.04.8) ...
Setting up gcc-5-cross-base (5.4.0-6ubuntu1~16.04.9cross1) ...
Setting up libc6-armel-cross (2.23-0ubuntu3cross1) ...
Setting up libgcc1-armel-cross (1:5.4.0-6ubuntu1~16.04.9cross1) ...
Setting up libgomp1-armel-cross (5.4.0-6ubuntu1~16.04.9cross1) ...
Setting up libatomic1-armel-cross (5.4.0-6ubuntu1~16.04.9cross1) ...
Setting up libasan2-armel-cross (5.4.0-6ubuntu1~16.04.9cross1) ...
Setting up libstdc++6-armel-cross (5.4.0-6ubuntu1~16.04.9cross1) ...
Setting up libubsan0-armel-cross (5.4.0-6ubuntu1~16.04.9cross1) ...
Setting up libgcc-5-dev-armel-cross (5.4.0-6ubuntu1~16.04.9cross1) ...
Setting up gcc-5-arm-linux-gnueabi (5.4.0-6ubuntu1~16.04.9cross1) ...
Setting up gcc-arm-linux-gnueabi (4:5.3.1-1ubuntu1) ...
Setting up linux-libc-dev-armel-cross (4.4.0-18.34cross1) ...
Setting up libc6-dev-armel-cross (2.23-0ubuntu3cross1) ...
Processing triggers for libc-bin (2.23-0ubuntu11.2) ...
Может у кого-то появится мысль.

Ps вдаваться в подробности что там за софтина - смысла нет (модифицированный исходник очень популярной консольной софтины под linux), т.к. скомпилированный по конфигу выше бинарник выдает «kernel too old». Последний раз компилировал удачно на голой Ubuntu эту сборку месяцев 7-9 назад.

Дополнил: Проблема не в том чтобы получить openssl (static) для целевого ядра, а найти решение как «откатить» gcc-arm-linux-gnueabi и/или или его зависимости, чтобы компилировать не получая «kernel too old», в том числе и для бинарника openssl. Openssl тут приведен вообще исключительно ради реального примера проблемы.


Лет 5 назад компилировал софтину для железке на ARM через arm-linux-gnueabi в режиме static. Она включала в себя openssl-1.0.2r

не включала. r вышел год с небольшим назад. и, собственно, чего ты хочешь от нас? чтобы у тебя было старое ядро, новая софтина, но не новая, а так, новая, но не совсем, чтобы в ней что-нибудь было старенькое?

pohepi ()

Зачем собирать openssl, он есть в репах той же версии. А вот его dev пакет хитро называется libssl-dev. Я не сразу догадался и тоже по дурости собирал сначала сам.

anonymous ()
Ответ на: комментарий от pohepi

Очевидно, что 5 лет назад openssl-1.0.2r не существовало. Если Вам так принципиальна эта опечатка, то можете читать как «Она включала в себя openssl». Хотя как по мне, то очевидно что указание версии тут лишнее. Моя проблема вовсе не в OpenSSL, и даже не в ее версии, у меня проблема с компилятором. Будь то сборка OpenSSL, или голый cpp «Hello World». Что я хочу - я написал. Мне не нужно старое ядро. Я выше написал, openssl-1.0.2r прекрасно компилируется (как и бинарник «софтины») на подсунутом gcc-linaro-6.5.0 (arm-linux-gnueabi), взятый с из репозитория linaro, он даже работает. Только размер бинарника x2. Выше написано что я хочу и это вовсе не «сломалась программа, не работает, а шо же теперь делать чтобы работала». Я указал все версии, тулчейны и какие пакеты и версии пакетов ставит ubuntu из своего репозитория. Т.к. мои знания линукс ограничиваются сугубо кокретными задачами, хотел услышать мысли, что из этого (пакетов и зависимостей) могло обновиться за 9 мес и «завысить» минимальное требование к версии целевого ядра, как эту проблему побороть (даунгрейдом пакетов, установкой другой версии пакетов…), но явно не «программка сломалась, ну а шо ты теперь от нас хочешь?».

doko ()
Ответ на: комментарий от anonymous

Попробую, но это борьба с симптомами. Хотелось бы решить причину. Если других решений не найду, то поптробую.

У меня конечный бинарник выходит 4Мб примерно (если не эта проблема). Для бинарника включающего в себя 3 статические библиотеки - я считаю это в рамках разумного. Мне важна универсальность и отсутствие необходимости компилировать под каждое устройство отдельный бинарник. Спасибо за совет.

doko ()
Ответ на: комментарий от doko

Очевидно, что 5 лет назад openssl-1.0.2r не существовало.

тогда тем более непонятно, зачем ты об этом пишешь

Если Вам так принципиальна эта опечатка, то можете читать как «Она включала в себя openssl». Хотя как по мне, то очевидно что указание версии тут лишнее.

чувак, ты просишь помощи с поиском версии программы и начинаешь с того, что постишь бредовую версию. так себе опечатка

Моя проблема вовсе не в OpenSSL, и даже не в ее версии, у меня проблема с компилятором. Будь то сборка OpenSSL, или голый cpp «Hello World».

ну и нахрена ты об этом писал тогда?

Что я хочу - я написал.

нет, не написал

Мне не нужно старое ядро.

ну так обнови ядро на целевой железке и не ной

Я выше написал, openssl-1.0.2r прекрасно компилируется (как и бинарник «софтины») на подсунутом gcc-linaro-6.5.0 (arm-linux-gnueabi), взятый с из репозитория linaro, он даже работает. Только размер бинарника x2.

так работает или kernel too old?

Выше написано что я хочу и это вовсе не «сломалась программа, не работает, а шо же теперь делать чтобы работала».

это там в том числе написано

Я указал все версии, тулчейны и какие пакеты и версии пакетов ставит ubuntu из своего репозитория.

нахрена? по-твоему мы не знаем, какие версии ставит стандартный установщик стандартной убунты?

Т.к. мои знания линукс ограничиваются сугубо кокретными задачами, хотел услышать мысли, что из этого (пакетов и зависимостей) могло обновиться за 9 мес и «завысить» минимальное требование к версии целевого ядра, как эту проблему побороть (даунгрейдом пакетов, установкой другой версии пакетов…), но явно не «программка сломалась, ну а шо ты теперь от нас хочешь?».

ты и со второй попытки не смог объяснить, что тебя не устраивает, размер бинарника или то, что он не работает. давай по-новой

pohepi ()
Ответ на: комментарий от pohepi

ну и нахрена ты об этом писал тогда? Ну так прочти мое сообщение выше и поймешь. Самое первое.

«ну так обнови ядро на целевой железке и не ной» Если бы я мог обновить ядро на целевой железке, то я бы сейчас не спрашивал как даунгредить GCC, чтобы скомпилировать под целевое ядро. Заметь, я не спрашивал как обновить целевое ядро и даже не намекал на это.

Думаю тебе отдельно повторить, чтобы ты долго не искал: Снес систему и на голую машину поставил [b]максимальную версию, которая не выдала ошибку «kernel too old» на конечном устройсте[/b], это arm-linux-gnueabi - [b]gcc-linaro-6.5.0[/b]-2018.12-x86_64_arm-linux-gnueabi, взятый с releases.linaro.org.

Так виднее? Я не знаю, есть ли тут выделение шрифта другим цветом, но если и в этот раз не увидишь, то я обязательно поищу как его сделать розовым для тебя.

doko ()
Ответ на: комментарий от pohepi

Давай еще раз, по старым граблям. Пересказываю. У меня есть софт. Этот софт скомпилен в режиме статитик, в один бинарник. В ТОМ ЧИСЛЕ в него входит openssl. Последний раз я собирал софт примерно 9 мес назад, на Убунту 18 (ну или 16, уже не помню). Пользовался всегда arm-linux-gnueabi-gcc из репозитория Убунты. Вчера сел повторить на голой системе и получил на целевой системе «FATAL: kernel too old». Т.е. за время 9 мес какой-то пакет из зависимостей кросс-компилера из репозитория Убунты обновил minimal kernel version, потому как GLIBC-2.23 и arm-linux-gnueabi-gcc-5.4.0 установленные должны иметь возможность компилировать под целевую версию ядра (по крайней мере из того, что я нашел в интернете это следует). При этом, убив установленный ранее arm-linux-gnueabi, я взял другой, с linaro.org, arm-linux-gnueabi-gcc-6.5.0. Он прекрасно скомпилировал и бинарник на целевой запустился без ошибок. Однако, мне этот вариант не особо подходит, т.к. размер бинарника и приемлемых 4Мб получается на этом arm-linux-gnueabi около 8Мб. По какой причине это происходит - не понятно. Потому я ищу возможность условно «откатить» версию GCC-arm (или скорее одну из зависимостей) из репозитория Убунты, например указанием конкретной версии пакета, чтобы получить компилятор «из прошлой счастливой жизни». Т.к. я в меру своих знаний не знаю зависимостей, с линуксом работаю крайне редко и обычно лишь делаю то, в чем есть необходимость, я прошу помощи, натолкнуть на мысль в каком конкретно пакете может быть проблема «minimal kernel version» вызывающая теперь FATAL: kernel too old. Я прекрасно помнимою, что софт обновляется, зависимости обновляются, что ядра устаревают и скомпилировать под старое ядро коммерческой железки известного производителя современный софт - проблема, учитывая отсутствие исходников ядра и ограничение в памяти. Я не вчера родился и не хожу по формам задавая вопросы что такое «ядро» и как посмотреть его версию. У меня есть решение моей проблемы, которое я описал выше, к которому я пришел сам, но оно меня не устраивает. Ну если ты считаешь, что это вопрос из области «сломалась программа, не работает, а шо же теперь делать чтобы работала», то ок. Видимо я о себе был большего мнения, можешь меня номинировать на звание «тупой вопрос года». Надеюсь 3й раз не придется разжевывать.

doko ()

Какой из компонентов мог обновиться и теперь имеет ограничения на минимальное ядро?

glibc. Причем значение имеет не конкретный номер версии glibc. При конфигурировании обычно задают параметр минимальной версии ядра, вот эта часть процесса сборки бинарника повлияла на результат.

--enable-kernel=version’
This option is currently only useful on GNU/Linux systems. The version parameter should have the form X.Y.Z and describes the smallest version of the Linux kernel the generated library is expected to support. The higher the version number is, the less compatibility code is added, and the faster the code gets.

В вашем случае это glibc, статически линкуемая в бинарник, т.е. из gnueabi тулчейна.

bormant ★★★★★ ()
Последнее исправление: bormant (всего исправлений: 2)
Ответ на: комментарий от bormant

Логика есть. Но мне кажется сомнительным, что при компиляции нового пакета glibc с измененным kernel ver. не происходит инкремент версии пакета. Ну даже если предположить, что обновленный glibc входит в состав нового дистрибутива ОС… так я брал старый дистрибутив, в списке обновлений при установке gcc-arm-linux-gnueabi из репозитория нет glibc. Т.е. он какой версии был в момент развертывания системы, такой и остался. Более того, 2.23 - это как раз последняя версия с поддержкой ядра ниже 3.2. Об этом сказано в релизе версии 2.24

The minimum Linux kernel version that this version of the GNU C ibrary can be used with is 3.2 Об этом я ранее сказал.

doko ()
Ответ на: комментарий от turtle_bazon

«Грепать» - это хорошо, но уж сильно пакетов много) Оставлю это как крайний вариант) 16 и 14 Убунту ставил. После установки arm-linux-gnueabi-gcc результат аналогичен. А вот с 12 вероятно стоит попробовать, вряд ли она поддерживается уже. Спасибо за совет.

doko ()

Подкинутая идея со стрипером меня привела к идеи поискать что есть в бинарнике, которой рабочий, скомилированный ранее.

GCC: (Ubuntu/Linaro 4.7.3-12ubuntu1) 4.7.3 GCC: (Ubuntu/Linaro 4.8.2-16ubuntu3) 4.8.2 A)

Вот что нашлось Определенно версия теперь известна. По крайней мере один из двух вариантов. Собственно это как я понимаю версии пакетов. Завтра попробую найти информацию как принудительно поставить этот пакет со своими зависимостями.

Скорее это информация не несет полезной нагрузки, но может кому пригодиться варианты где можно поискать.

doko ()

Частично решил проблему подобрав оптимальный тулчейн

gcc-linaro-4.9.4-2017.01-x86_64_arm-linux-gnueabi.tar.xz

В моем случае. Также пробовал установить принудительно пакеты 4.7 и 4.8 arm-linux-gnueabi из репозитория, но не все мои библиотеки для софта собирались. OpenSSL собрался, кстати. Размер все еще далек от приемлемого, но удалось сократить его значительно. Спасибо всем кто подкинул идей.

doko ()
Последнее исправление: doko (всего исправлений: 2)