Question

我正在尝试使用linux内核3.10-2-amd64在x86_64上构建uClibc 0.9.27 ^[1]。我可以验证它是基于Ubuntu 12.04.3和3.2.0-49通用内核构建的。在运行make时，它会设法构建大量目标文件但最终到达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，尽管os文件的CC看起来很奇怪），然后修改cc命令以捕获预处理的输出。

例如，要从中获取预处理输出：

cc -c prog.c -o prog.o

使用此intead：

cc -E prog.c >prog.i

然后通过prog.i搜索有问题的行。找到特定的行号是很棘手的，所以最好搜索文本 - 虽然这也很棘手，因为有些词会被预处理器取代。这里的好消息是输出将告诉您编译器尝试编译的确切内容 - 在处理完所有包含并应用宏之后。只是“纯C”代码。

在可行的版本和不适用的版本上执行此操作，并查看__kernel_long_t在良好版本上的内容中的哪些内容，然后尝试找出失败的版本上未发生的原因。< / p>

请注意如下所示的行：

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

表示“/usr/include/stdio.h”的“第443行”是输出文件中的下一行。

要查看定义在源中的位置，请从包含定义的行中搜索，可能是问题中指示的typedef，然后使用文件名搜索上面的第一行 - 这是从中获取的文件它是获得的。向上走，看看文件的位置。请注意，它不一定是上面的下一个文件，因此请核实原始来源。这样做，最终您将找到包含具有该定义的文件的打包源的部分。然后应该可以弄清楚为什么在另一个构建中没有使用该行，或者相同的include不会导致该类型的定义。

请注意，我假设发布的错误消息表明问题是__kernel_long_t缺少定义。在使用该类型之前，错误可能意味着什么。

我希望这会有所帮助。

由于缺少类型，构建uclibc linux 3.10-2（Debian jessie x86_64）失败

2 个答案: