Зачем нужны linux-headers?
pascorp 22 апреля, 2017 - 11:10
Собственно интересует зачем нужен пакет linux-headers? Ведь при сборке ядра заголовочные файлы ядра и так устанавливаются.
»
- Для комментирования войдите или зарегистрируйтесь
а вдруг ты такой вот любитель
а вдруг ты такой вот любитель "заморозки истемы"? (есть тут один). То есть ты собрал ядро и грохнул исходники?
или ты вообще не собирал ядро, а утащил с LiveCD?
вообще вариантов, когда у тебя нет исходника ядра под рукой, но при этом система вполне себе штатно работает - великое множество. Вот на все такие случаи - как раз нужны заголовки.
Пользуясь моментом, хочу передать привет друзьям, которые также пользуются "Моментом"
Спасибо
Спасибо
В принципе ядро и система
В принципе ядро и система могут быть собраны с разными заголовками. Например, рекомендуется держать заголовки ядра и системы одинаковыми, но достаточно часто случаются ситуации, когда ядро обновляют, а системные заголовки - нет, потому как их изменение требует пересборки glibc, a это, как правило, влечет за собой пересборку мира.
Продолжение вопроса
Всем доброго времени суток.
В продолжение вопроса - почему стабильные версии sys-kernel/linux-headers (4.4) и sys-kernel/gentoo-sources (4.9) различаются?
Выходит, что ядро признано стабильным, а заголовки этого ядра нет?
Есть мнение, что
linux-headers стабилизируются вместе с очередной версией glibc. Ядро обновляется гораздо чаще, и каждый раз делать новую версию linux-headers стабильной вслед за ядром чревато проблемами с компиляцией пакетов - glibc будет собрана с одной версией заголовков, а пакет будет пытаться собираться с другой.
.
Осталось объяснить причины, по которым офф. руководство (Upgrading_GCC) утверждает… скажем «опциональность» пересборки мира с новым GCC.
:wq
--
Live free or die
Ты просто невнимательно
Где это ты такое увидел?!..
Ты просто невнимательно читал! :)
Там есть и пояснение когда и почему... могу даже процитировать:
Попросту говоря, некоторые пакеты не зависят от GCC, ибо используют только BASH, PERL, Python, Ruby и пр. Так что для тех, кто хорошо знаком с С, с (динамическими) библиотеками в Линуксе и с системой вообще, должно быть понятно когда и что перекомпилировать, а для остальных проще пересобрать, чтобы не иметь проблем сейчас и/или потом!.. ;)
.
Вестимо, в статье ☺
Это от того, что в вики горга я обычно пишу. Точнее — переписываю откровенную ахинею и явные ошибки (коллизии логики естественного языка с конкретной реализацией) ☺
Цитируй. Почитаем вместе.
Первый информационный абзац — описание оптимизаций поддержки конкретных инструкций/процессоров с оговорками о ничтожности области применимости.
Туда же можно добавить, что в тех же пакетах влияние способа указания и перечень CFLAGS проявляется независимо от версии компиллятора.
Второй информационный абзац — оговорка о разделяемых библиотеках. Но там же прямое указание на практикуемый способ решения (version bump в одном коммите решает проблему).
Из не сказанного по личному опыту могу добавить регулярно встречающиеся проблемы полноты/корректности скриптов сборки. Которые адекватно отлаживаются только на маршрутах, практикуемых апстримом, а разработчики последнее время склонны халявить и увлекаться разного рода portable-версиями. Так что вероятность налететь на необходимость определённого порядка сборки зависимостей даже в рамках одной версии компиллятора… из моей практики превосходит вероятность проблем, вызванных использованием различных версий компиллятора.
Впрочем, результат тут зависит от индивидуальных наборов используемого ПО и таблицы приоритетов.
:wq
--
Live free or die
чукча не читатель, чукча - писатель! (С)
Да уж давно ясно, что "...чукча не читатель, чукча - писатель!" (С) :)
Попробуй все-таки внимательно перечитать мой пост! Там я о том и говорю: кто понимает что и как - знает и когда и что перекомпилировать, а для остальных пересборка никогда не повредит!
.
Надо же как-то компенсировать идейных не-писателей… ☺
Которые не только до офф. вики дойти ленятся, но даже зафиксировать своё мнение в локальном ЧаВо не хотят.
Хотя например мне было бы интересно обнаружить хотя бы в официальной документации, не говоря о цитированном фрагменте, упоминания о:
О приведении дистрибутивной политики стабилизации ядра в соответствие с:
и не мечтаю.
На этот случай обычно новости есть.
Например по последнему эпизоду:
[33] 2015-10-22 GCC 5 Defaults to the New C++11 ABI
::wq
--
Live free or die
SysA написал(а): ...а для
Переустановка тоже не повредит. Вдруг у меня еще что-то древнее осталось?)))
Вообще, кстати, после обновления glibc ТОЧНО не надо ничего пересобирать. Если, конечно, маэстро не желает страстно наблюдать бегущие строки от выводов make.
Поясню логику своей насмешки. Ежели уважаемый прав и необходимо действительно пересобирать всю бинарную часть системы - тогда обновление любого грамотно построенного бинарного дистра, содержащее glibc - будет тащить также и половину системы с собой тупо перекомпиленную, ведь так? А этого не наблюдается. Можно, конечно, съехать, сказав, что дистростроители - сирые и убогие и делают все не так, но это классическая ситуация "все козлы, один я д'Артаньян"
Пользуясь моментом, хочу передать привет друзьям, которые также пользуются "Моментом"
.
Для связности пока просто отмечу возражение SysA при обсуждении того же вопроса в другой теме.
А вообще надо бы собраться и рассмотреть теорию.
ЗЫ: Как ни печально, но ситуация «все козлы, один я д'Артаньян» не настолько невероятна, как представляется.
:wq
--
Live free or die
Думается мне, что грубым
Думается мне, что грубым методом "собрать мнение всех в большей степени компетентных товарищей по одному и тому же вопросу и вывести общий знаменатель" мы можем получить достаточно применимую на практике документацию.
Было бы очень хорошо иметь широкую вику с советами типа "вот поймал такую траблу - решил ее вот так-то". Очень полезная вещь.
Пользуясь моментом, хочу передать привет друзьям, которые также пользуются "Моментом"