Построение uclibc linux 3.10-2 (Debian jessie x86_64) не удается из-за отсутствующих типов

Question

Я пытаюсь построить uClibc 0.9.27 ^[1] на x86_64 с ядром linux 3.10-2-amd64. Я могу проверить, что он построен на Ubuntu 12.04.3 с ядром 3.2.0-49. При запуске сделать, это удается построить много объектных файлов, но в конечном итоге достигает CC libc/inet/if_index.os, жалуясь с

In file included from /usr/include/linux/kernel.h:4, 
       from /usr/include/linux/netlink.h:4, 
       from /usr/include/linux/rtnetlink.h:5, 
       from libc/inet/netlinkaccess.h:32, 
       from libc/inet/if_index.c:36: 
/usr/include/linux/sysinfo.h:8: error: expected specifier-qualifier-list before '__kernel_long_t' 
In file included from /usr/include/linux/rtnetlink.h:6, 
       from libc/inet/netlinkaccess.h:32, 
       from libc/inet/if_index.c:36: 
/usr/include/linux/if_link.h:317: error: expected specifier-qualifier-list before '__be16' 

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

/usr/include/linux/sysinfo.h includes <linux/types.h> 
/usr/include/linux/types.h includes <linux/posix_types.h> 
/usr/include/linux/posix_types.h includes <asm/posix_types.h> 
/usr/include/x86_64-linux-gnu/asm/posix_types.h includes <asm/posix_types_64.h> 
/usr/include/x86_64-linux-gnu/asm/posix_types_64.h includes <asm-generic/posix_types.h> 
/usr/include/asm-generic/posix_types.h typedefs __kernel_long_t 

Итак, где же эта ошибка берутся, и как я могу это исправить?

---

^[1] Да, я знаю, что новая версия 0.9.33.2, но мне нужно эту конкретную версию.

Answer 1

Решение похоже на обратную передачу более новой версии libc/inet/netlinkacces.h в более раннюю версию. Проблема __kernel_long_t устраняется путем исключения включения (если необходимо, это должно быть исправлено в kernel_types.h, так как определено намеренно теневое включение защитных ограждений заголовков в /usr/include), а другие типы (ы) могут быть правильно включены следующим патч:

index 417d83a..1b9c857 100644 
--- a/libc/inet/netlinkaccess.h 
+++ b/libc/inet/netlinkaccess.h 
@@ -21,16 +21,7 @@ 

#include <features.h> 
#include <stdint.h> 
-#include <sys/types.h> 
- 
-#define _LINUX_TYPES_H 
-typedef uint8_t __u8; 
-typedef uint16_t __u16; 
-typedef uint32_t __u32; 
-typedef uint64_t __u64; 
-typedef int32_t __s32; 
-#include <linux/rtnetlink.h> 
-#include <linux/netlink.h> 
+#include <unistd.h> 

/* Should prob be a configure option or something */ 
#ifndef __ASSUME_NETLINK_SUPPORT 

в основном это изменение между старым netlinkaccess.h и один в новой версии (сравнивает из препроцессированных файлов, предложенных ash намекнул мне на это).

Answer 2

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

Эта проблема сложна для отслеживания, так как это пакет сторонних производителей, включающий в себя. И, если он написан для построения нескольких архитектур, он, вероятно, будет содержать множество предпроцессорных директив, из-за которых сложно даже знать, какой код действительно используется.

Я рекомендую захватить команду, которая генерирует ошибку (похоже, это может быть CC libc/inet/if_index.os, хотя CC файла os кажется странным), а затем измените команду cc, чтобы захватить предварительно обработанный вывод.

Например, чтобы получить препроцессированный выход из этого:

cc -c prog.c -o prog.o 

Используйте этот Intead:

cc -E prog.c >prog.i 

Тогда поиск хотя prog.i для рассматриваемой линии. Трудно найти конкретные номера строк, поэтому лучше всего искать текст - хотя это тоже сложно, поскольку некоторые слова будут заменены препроцессором. Хорошая новость заключается в том, что на выходе будет указано, что именно компилятор пытается скомпилировать - в конце концов были обработаны и применены макросы. Просто "чистый C" код.

Сделайте это на версии, которая работает, а другая нет, и посмотрите, где __kernel_long_t получает в сборку на хорошем, а затем попытайтесь найти, почему этого не происходит на сбоя.

Обратите внимание на линии, которые выглядят так:

# 443 "/usr/include/stdio.h" 

среднее «строка 443» из «/usr/include/stdio.h» является следующая строка выходного файла.

Чтобы узнать, куда в исходное положение входит определение, найдите строку, содержащую определение, возможно, typedef, как указано в вопросе, и выполните поиск первой строки над ней с именем файла - это файл из который был получен. Поднимитесь еще раз, чтобы увидеть, где был вложен этот файл. Обратите внимание, что это не обязательно будет следующий файл выше, поэтому убедитесь, что исходные источники. Сделав это, вы, в конце концов, найдете часть упакованных источников, в которую входит файл с этим определением. Тогда должно быть возможно выяснить, почему либо эта строка не используется в другой сборке, или что то же самое включает не приводит к определению типа.

Обратите внимание, что я предполагаю, что сообщения об ошибках означают, что проблема - это недостающее определение для __kernel_long_t. Ошибка может означать что-то непосредственно перед тем, как использование этого типа является проблемой.

Надеюсь, это поможет.