Помогите kernel и glibc нужно ли пересобирать

libc при смене ядра пересобирать не надо.

равно как не надо менять /usr/include/{asm,linux}
в этих каталогах должны быть те файлы, которые
использовались при сборке libc.

А как тогда быть с тем что при включении в текст программы заголовочных файлов и glibc и linux kernel?? Документацию по glibc и LFS я прочитал. Там как раз мой случай и не рассматривается.

Получается включая glibc я включаю заголовки старого ядра поэтому появляются ошибки типа

In file included from /lib/modules/2.6.10/build/include/linux/sched.h:31, from main.c:11: /lib/modules/2.6.10/build/include/linux/percpu.h: In function `__alloc_percpu': /lib/modules/2.6.10/build/include/linux/percpu.h:45: error: `GFP_KERNEL' undeclared (first use in this function) /lib/modules/2.6.10/build/include/linux/percpu.h:45: warning: initialization makes pointer from integer without a cast In file included from /lib/modules/2.6.10-omap1/build/include/linux/sched.h:32, from main.c:11: /lib/modules/2.6.10/build/include/linux/topology.h: In function `__next_node_with_cpus': /lib/modules/2.6.10/build/include/linux/topology.h:50: error: `numnodes' undeclared (first use in this function) /lib/modules/2.6.10/build/include/linux/topology.h:50: error: parse error before "__tmp__" /lib/modules/2.6.10/build/include/linux/topology.h:50: error: `__tmp__' undeclared (first use in this function)

в одних и тех же файлах функции определенны по разному, или их нет если я не включаю заголовки нового ядра. Ядро постоянно в развитии. Вот я и думаю сижу.

Вопрос не такой простой как кажется на первый взгляд.

> Вопрос не такой простой как кажется на первый взгляд.

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

если вы пишете user-level приложение, то вы вообще не
должны использовать (явно) kernel includes. если это
все-таки тот редкий случай, когда это необходимо, тогда
вы не должны задавать подобных вопросов :)

если вы компилируете, к примеру, модуль, вам не нужны
includes от libc.

> Получается включая glibc я включаю заголовки старого ядра

да, это нормально и _правильно_, если речь идет, опять-таки,
о user level коде.

>вопрос очень простой, обсуждался до смерти на разных форумах, и ответ на него вы получили.

Молодой девелопер оставшийся во главе проекта, когда его покинул тот кто эту кашу заварил, и не такое спросит. Да и термин user-level приложение ты idle неправильно используеш поскольку приложение всегда выполняются в user-level, если ты о уровне привилегий.

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

Хотя может я и не прав. Лучше уж отправь в те форумы где это обсуждалось до смерти.

Спасибо за поддержку и с праздником.

> Да и термин user-level приложение ты idle неправильно используеш

я не знал, что этот термин имеет более или менее формальное
определение.

> поскольку приложение всегда выполняются в user-level, если ты о
> уровне привилегий.

я не об этом.

> Но я уже разобрался нужно обновить glibc,

еще раз: не нужно. в смысле, в этом _нет_ необходимости.

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

именно их и нужно включать! а вот новые - не надо.
если, конечно, вы не модуль ядра компилируете.

если же это все-таки модуль, то вообще непонятно, 
при чем здесь libc.

> Лучше уж отправь в те форумы где это обсуждалось до смерти.

lkml

Мне кажется я допёр поправте если не так пожалуйста.

Если моё приложение будет использовать API ядра и glibc то пересборка может будет нужна а может и нет.

Если API ядра в необходимой мне части не менялось с тех пор как я собрал glibc то пересобирать не надо. Но если изменилось, допустим добавили новую функцию или изменили список параметров и мне эта функция необходима, то придётся пересобрать glibc с новыми заголовочными файлами ядра. Иначе будут ошибки с несовпадением типов. Что я и имел.

> Если API ядра в необходимой мне части не менялось с тех пор как я собрал glibc то пересобирать не надо. Но если
> изменилось, допустим добавили новую функцию или изменили список параметров и мне эта функция необходима, то придётся
> пересобрать glibc с новыми заголовочными файлами ядра. Иначе будут ошибки с несовпадением типов. Что я и имел.

если добавилась новая функция (syscall), то libc пересобирать
не надо, он про нее все равно не знает.

если изменили список параметров функции видимой user-level, то
такого не бывает, потому что user-level api не меняется никогда.
вводится новая функция, напр sys_rt_sigaction().

> Если моё приложение будет использовать API ядра

что вы имеете в виду? единственный доступный из user-level
api - это syscall.

иногда _действительно_ нужно знать внутренее предствление
каких-то private данных (например, вы пишете загрузку модулей),
но в таких случаях вы не пользуетесь для этого libc, и его
опять-таки не надо пересобирать.

> Иначе будут ошибки с несовпадением типов. Что я и имел.

что конкретно у вас было?

серьезно, я никак не пойму, почему вы не можете понять
такую простую вещь.

повторю еще раз (третий): libc пересобирать не надо.
у меня вообще /lib/libc-2.1.2.so.

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