>> А если это пользователь компилятора? :)
> Изен как пользователь компилятора... это такая обезьяна с гранатой версии 2.0.Так проверяются на "вшивость" исходники, компайлеры и люди заодно. Люди, переходящие от предмета обсуждения на личности для меня убоги и ограничены в своём развитии.
> Взять недефолтный компилер и какой-то более свежий код - это хорошая заявка на поимение проблем.
Взять современный недефолтный компайлер — хорошая заявка на проверку как исходных текстов на наличие косяков разработчиков, так и самого компилятора на профпригодность. То есть язык программирования, в данном случае Си, является той точкой пересечения интересов разработчиков системы и компилятора, где сходятся две проблемы: корректности описания предметной области на ЯВУ и перевода в машинную форму.
Сомневаюсь, что Linux ядро сходу можно было бы собрать последним компилятором GCC, не говоря уж о Clang.
> Может у него объектник устарел относительно сорца а билдсистема это прошляпила? Ну
> то-есть в сферическом случае в вакууме я бы попробовал ресинк исходников
> в надежде что десинк кусков между собой прихлопали, а потом полный
> сlean всех объектников, с ручной проверкой что объектников нигде не осталось
> и ребилд заново. Но это больше прокатывает для обычного софта, как
> оно в фрибзде - пусть изя и разбирается.
О каком ресинке вы говорите? /usr/src перезаливал много раз. Проблема повторяется. Причём для разных ревизий вылезает в разных местах, и каталог /usr/include в этом замешан, так как он не синкается по svn, а используется опосредованно в процессе пересборки.
У меня подозрение, что сборочная система использует данные из каталога /usr/include текущей версии/ревизии для сборки новой версии (в которой некоторые исходники из /usr/src могут кардинально отличаться от "парных" им заголовочных файлов в /usr/include), а уже после установки новой сборки make обновляет каталог /usr/include для приведение в соответствие заголовочных файлов установленным бинарникам. Я прав?
