ndk-build无法找到arm或mips标头

时间:2013-11-27 01:45:23

标签: android eclipse android-ndk

当我尝试在Windows下使用Eclipse构建时,我有以下令人困惑的输出(额外路径缩写为'*'):

*\android-ndk-r9b-windows-x86_64\android-ndk-r9b\ndk-build.cmd 
[x86] Compile        : P1 <= CompilationUnitC.c
[x86] Compile++      : P1 <= CompilationUnitCPP.cpp
[x86] SharedLibrary  : libP1.so
[x86] Install        : libP1.so => libs/x86/libP1.so
[armeabi] Compile thumb  : P1 <= CompilationUnitC.c
[armeabi] Compile++ thumb: P1 <= CompilationUnitCPP.cpp
In file included from */P1/Android//jni/CompilationUnitCPP.cpp:9:0:
*/P1/Android//jni/../../../Engine/Audio/AudioSystemAndroid.cpp:15:27: fatal error: SLES/OpenSLES.h: No such file or directory
compilation terminated.

这恰好是我制作的第一个外国人。如果我删除了这个包含,我会遇到与stblib.h相同的问题(!)

我在MacOS X下使用相同的项目数据没有这个问题

我特别困惑的是工具如何找到x86标头而不是arm标头。我已经看到这种配置在几个orroids之前工作得很好......我想知道是否有一些重大变化,现在需要进行一些Windows特定的配置。

我已经看到了一些看起来像我的问题的问题,但仔细检查是完全无关的。这似乎是一个明显的问题,如果有一个问题和答案埋没在所有分心之下,我不会感到惊讶......

1 个答案:

答案 0 :(得分:0)

因此,在某些时候进行了重大更改,以便从jni文件夹中运行ndk-build不起作用。

我的'修复'是从项目根目录运行它并调整我的其他包含路径以反映这一点。

虽然这是有效的,但令人非常不安。这不应该是一个修复......我在这里可以想到的是,在ndk-build中存在一些特别令人讨厌的hackery,它依赖于路径无关紧要。即使这样,我也很难想象这会如何阻止编译器在一条遥远而无关的路径中找到包含,特别是对于一个平台。

在我对没有真正的答复感到满意之前,我不会接受我自己的答案。如果有人能说清楚为什么会这样,那我肯定会感激不尽。我更喜欢能够理解修复,而不是像伏都教那样使用它。

相关问题