Зачем нужны linux-headers?

Собственно интересует зачем нужен пакет linux-headers? Ведь при сборке ядра заголовочные файлы ядра и так устанавливаются.

а вдруг ты такой вот любитель

а вдруг ты такой вот любитель "заморозки истемы"? (есть тут один). То есть ты собрал ядро и грохнул исходники?
или ты вообще не собирал ядро, а утащил с LiveCD?
вообще вариантов, когда у тебя нет исходника ядра под рукой, но при этом система вполне себе штатно работает - великое множество. Вот на все такие случаи - как раз нужны заголовки.

Пользуясь моментом, хочу передать привет друзьям, которые также пользуются "Моментом"

Спасибо

Спасибо

В принципе ядро и система

В принципе ядро и система могут быть собраны с разными заголовками. Например, рекомендуется держать заголовки ядра и системы одинаковыми, но достаточно часто случаются ситуации, когда ядро обновляют, а системные заголовки - нет, потому как их изменение требует пересборки glibc, a это, как правило, влечет за собой пересборку мира.

Продолжение вопроса

Всем доброго времени суток.
В продолжение вопроса - почему стабильные версии sys-kernel/linux-headers (4.4) и sys-kernel/gentoo-sources (4.9) различаются?
Выходит, что ядро признано стабильным, а заголовки этого ядра нет?

Есть мнение, что

linux-headers стабилизируются вместе с очередной версией glibc. Ядро обновляется гораздо чаще, и каждый раз делать новую версию linux-headers стабильной вслед за ядром чревато проблемами с компиляцией пакетов - glibc будет собрана с одной версией заголовков, а пакет будет пытаться собираться с другой.

.

SysA написал(а):
…системные заголовки - нет, потому как их изменение требует пересборки glibc, a это, как правило, влечет за собой пересборку мира.

Осталось объяснить причины, по которым офф. руководство (Upgrading_GCC) утверждает… скажем «опциональность» пересборки мира с новым GCC.

:wq
--
Live free or die

Ты просто невнимательно

Anarchist написал(а):
...офф. руководство (Upgrading_GCC) утверждает… скажем «опциональность» пересборки мира с новым GCC

Где это ты такое увидел?!..

Ты просто невнимательно читал! :)
Там есть и пояснение когда и почему... могу даже процитировать:

Rebuilding everything

Some people swear that they need to rebuild every single package on their system when a new GCC version is made available. Of course, that doesn't make sense, since there are many applications that are not using GCC for their build and install process anyhow, so they would never be affected by such changes.

That however doesn't mean they are completely incorrect: newer GCC versions often include better support for the processors' instruction set, which might influence the performance of some applications in a positive way. Although it is expected that this improvement is generally only marginal, in some cases (especially CPU intensive applications) this might yield notable improvements.

There are also known cases where packages need to be built with the same compiler. Although these packages are usually bumped by package maintainers simultaneously (so that they are always built with the same GCC version) cherry-picking re-installs on these packages might prove to be troublesome. The various qt-* packages are a nice example on this matter.

Попросту говоря, некоторые пакеты не зависят от GCC, ибо используют только BASH, PERL, Python, Ruby и пр. Так что для тех, кто хорошо знаком с С, с (динамическими) библиотеками в Линуксе и с системой вообще, должно быть понятно когда и что перекомпилировать, а для остальных проще пересобрать, чтобы не иметь проблем сейчас и/или потом!.. ;)

.

SysA написал(а):
Anarchist написал(а):
...офф. руководство (Upgrading_GCC) утверждает… скажем «опциональность» пересборки мира с новым GCC

Где это ты такое увидел?!..

Вестимо, в статье ☺

SysA написал(а):
Ты просто невнимательно читал! :)

Это от того, что в вики горга я обычно пишу. Точнее — переписываю откровенную ахинею и явные ошибки (коллизии логики естественного языка с конкретной реализацией) ☺

SysA написал(а):
Там есть и пояснение когда и почему... могу даже процитировать:

Rebuilding everything

Some people swear that they need to rebuild every single package on their system when a new GCC version is made available. Of course, that doesn't make sense, since there are many applications that are not using GCC for their build and install process anyhow, so they would never be affected by such changes.

That however doesn't mean they are completely incorrect: newer GCC versions often include better support for the processors' instruction set, which might influence the performance of some applications in a positive way. Although it is expected that this improvement is generally only marginal, in some cases (especially CPU intensive applications) this might yield notable improvements.

There are also known cases where packages need to be built with the same compiler. Although these packages are usually bumped by package maintainers simultaneously (so that they are always built with the same GCC version) cherry-picking re-installs on these packages might prove to be troublesome. The various qt-* packages are a nice example on this matter.

Попросту говоря, некоторые пакеты не зависят от GCC, ибо используют только BASH, PERL, Python, Ruby и пр. Так что для тех, кто хорошо знаком с С, с (динамическими) библиотеками в Линуксе и с системой вообще, должно быть понятно когда и что перекомпилировать, а для остальных проще пересобрать, чтобы не иметь проблем сейчас и/или потом!.. ;)

Цитируй. Почитаем вместе.

Первый информационный абзац — описание оптимизаций поддержки конкретных инструкций/процессоров с оговорками о ничтожности области применимости.
Туда же можно добавить, что в тех же пакетах влияние способа указания и перечень CFLAGS проявляется независимо от версии компиллятора.

Второй информационный абзац — оговорка о разделяемых библиотеках. Но там же прямое указание на практикуемый способ решения (version bump в одном коммите решает проблему).
Из не сказанного по личному опыту могу добавить регулярно встречающиеся проблемы полноты/корректности скриптов сборки. Которые адекватно отлаживаются только на маршрутах, практикуемых апстримом, а разработчики последнее время склонны халявить и увлекаться разного рода portable-версиями. Так что вероятность налететь на необходимость определённого порядка сборки зависимостей даже в рамках одной версии компиллятора… из моей практики превосходит вероятность проблем, вызванных использованием различных версий компиллятора.

Впрочем, результат тут зависит от индивидуальных наборов используемого ПО и таблицы приоритетов.

:wq
--
Live free or die

чукча не читатель, чукча - писатель! (С)

Anarchist написал(а):
SysA написал(а):
Ты просто невнимательно читал! :)

Это от того, что в вики горга я обычно пишу. Точнее — переписываю...

Да уж давно ясно, что "...чукча не читатель, чукча - писатель!" (С) :)

Anarchist написал(а):
Впрочем, результат тут зависит от индивидуальных наборов используемого ПО и таблицы приоритетов.

Попробуй все-таки внимательно перечитать мой пост! Там я о том и говорю: кто понимает что и как - знает и когда и что перекомпилировать, а для остальных пересборка никогда не повредит!

.

SysA написал(а):
Да уж давно ясно, что "...чукча не читатель, чукча - писатель!" (С) :)

Надо же как-то компенсировать идейных не-писателей… ☺
Которые не только до офф. вики дойти ленятся, но даже зафиксировать своё мнение в локальном ЧаВо не хотят.

Хотя например мне было бы интересно обнаружить хотя бы в официальной документации, не говоря о цитированном фрагменте, упоминания о:

2.5. emerge -1 --nodeps glibc binutils gcc если обновился/изменился хотя бы один из пакетов тулчейна.

О приведении дистрибутивной политики стабилизации ядра в соответствие с:

3. если надо изменить/обновить ядро, то это надо делать только после обновления тулчейна (п.2), а также рекомендуется перекомпилировать ядро, если обновился тулчейн.

и не мечтаю.

SysA написал(а):
Anarchist написал(а):
Впрочем, результат тут зависит от индивидуальных наборов используемого ПО и таблицы приоритетов.

Попробуй все-таки внимательно перечитать мой пост! Там я о том и говорю: кто понимает что и как - знает и когда и что перекомпилировать, а для остальных пересборка никогда не повредит!

На этот случай обычно новости есть.
Например по последнему эпизоду:
[33] 2015-10-22 GCC 5 Defaults to the New C++11 ABI:

…
GCC 5 uses the new C++ ABI by default.  When building new code, you might run
into link time errors that include lines similar to:
...: undefined reference to '_ZNSt6chrono12steady_clock3nowEv@GLIBCXX_3.4.17'

Or you might see linkage failures with "std::__cxx11::string" in the output.

These are signs that you need to rebuild packages using the new C++ ABI.
You can quickly do so by using revdep-rebuild (from gentoolkit).

For gentoolkit-0.3.1 or higher:
# revdep-rebuild --library 'libstdc++.so.6' -- --exclude gcc
…

:wq
--
Live free or die

SysA написал(а): ...а для

SysA написал(а):
...а для остальных пересборка никогда не повредит!

Переустановка тоже не повредит. Вдруг у меня еще что-то древнее осталось?)))

Вообще, кстати, после обновления glibc ТОЧНО не надо ничего пересобирать. Если, конечно, маэстро не желает страстно наблюдать бегущие строки от выводов make.

Поясню логику своей насмешки. Ежели уважаемый прав и необходимо действительно пересобирать всю бинарную часть системы - тогда обновление любого грамотно построенного бинарного дистра, содержащее glibc - будет тащить также и половину системы с собой тупо перекомпиленную, ведь так? А этого не наблюдается. Можно, конечно, съехать, сказав, что дистростроители - сирые и убогие и делают все не так, но это классическая ситуация "все козлы, один я д'Артаньян"

Пользуясь моментом, хочу передать привет друзьям, которые также пользуются "Моментом"

.

Для связности пока просто отмечу возражение SysA при обсуждении того же вопроса в другой теме.
А вообще надо бы собраться и рассмотреть теорию.

ЗЫ: Как ни печально, но ситуация «все козлы, один я д'Артаньян» не настолько невероятна, как представляется.

:wq
--
Live free or die

Думается мне, что грубым

Думается мне, что грубым методом "собрать мнение всех в большей степени компетентных товарищей по одному и тому же вопросу и вывести общий знаменатель" мы можем получить достаточно применимую на практике документацию.

Было бы очень хорошо иметь широкую вику с советами типа "вот поймал такую траблу - решил ее вот так-то". Очень полезная вещь.

Пользуясь моментом, хочу передать привет друзьям, которые также пользуются "Моментом"

Настройки просмотра комментариев

Выберите нужный метод показа комментариев и нажмите "Сохранить установки".