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

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

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

В Ubuntu 16.04 ядро 4.4 из коробки https://packages.ubuntu.com/xenial/linux-generic

Для конечной железки это овердохрена

Стрипать не пробовал?

sudo apt install strip-nondeterminism dh-strip-nondeterminism
strip --strip-unneeded

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

Очевидно, что 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 мес и «завысить» минимальное требование к версии целевого ядра, как эту проблему побороть (даунгрейдом пакетов, установкой другой версии пакетов…), но явно не «программка сломалась, ну а шо ты теперь от нас хочешь?».

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

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

Очевидно, что 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 мес и «завысить» минимальное требование к версии целевого ядра, как эту проблему побороть (даунгрейдом пакетов, установкой другой версии пакетов…), но явно не «программка сломалась, ну а шо ты теперь от нас хочешь?».

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

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

«ну так обнови ядро на целевой железке и не ной» Если бы я мог обновить ядро на целевой железке, то я бы сейчас не спрашивал как даунгредить 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.

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

да пиши хоть салатовым на жёлтом фоне, как описание того, что ты сделал, должно понять, чего ты хочешь добиться?

Давай еще раз, по старым граблям. Пересказываю. У меня есть софт. Этот софт скомпилен в режиме статитик, в один бинарник. В ТОМ ЧИСЛЕ в него входит 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й раз не придется разжевывать.

а вот нахрена ты всё полез пересобирать, если оно у тебя работало, клован.

Вероятно за тем, чтобы изменить код в исходнике на необходимый)

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

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

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 с измененным 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 Об этом я ранее сказал.

Версию пакета вам не с чем сравнивать, вы же не помните, какой версии был пакет libc6-dev-armel-cross когда было все хорошо?

Ну тут мыслей нет. Погрепать по исходникам всех компонентов разве что. :) Ну а вообще, бери 16 убунту, потом 14, потом 12. На какой-нибудь нормально соберётся. Её и оставь.

Нет. Естественно не помню. Да и не смотрел даже. Почем зря.

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

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

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

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

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

Есть еще полезная команда

readelf -d бинарник

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

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

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