I just updated from 0.8.14 to 1.0 RC4 and now my NDK support seems broken.
The failing ndk-build call:
C:\Users\layer0\AppData\Local\Android\android-ndk32-r10b-windows-x86_64\ndk-build.cmd NDK_PROJECT_PATH=null APP_BUILD_SCRIPT=C:\Users\layer0\AndroidStudioProjects\GameEngine\app\build\intermediates\ndk\debug\Android.mk APP_PLATFORM=android-20
NDK_OUT=C:\Users\layer0\AndroidStudioProjects\GameEngine\app\build\intermediates\ndk\debug\obj NDK_LIBS_OUT=C:\Users\layer0\AndroidStudioProjects\GameEngine\app\build\intermediates\ndk\debug\lib APP_ABI=all
Error message from make:
make.exe: *** No rule to make target C:\Users\layer0\AndroidStudioProjects\GameEngine\app\build\intermediates\ndk\debug\obj/local/armeabi-v7a/objs/my-jni/C_\Users\layer0\AndroidStudioProjects\GameEngine\app\src\main\jni',
needed by C:\Users\layer0\AndroidStudioProjects\GameEngine\app\build\intermediates\ndk\debug\obj/local/armeabi-v7a/objs/my-jni/C_\Users\layer0\AndroidStudioProjects\GameEngine\app\src\main\jni\buffercopies.o'. Stop.
The whole project, including the JNI parts was compiling fine just hours ago before the update. I guess something changed in the configs or about the supported ABIs?
But i don't really know what to look for.
Write it down, think, try again ... find a solution. grrrr
Effect was this bug:
https://code.google.com/p/android/issues/detail?id=66937
Issue 66937: "no rule to make target" when compiling only one .c file with ndk-build.cmd launched from gradle
Once the .so files are created the dummy.c file can be removed. I did that and forgot about the bug, so it came back after the update.
Related
I am trying to get a Visual Studio 2017 project to link, but I'm stuck on the following linker error:
LINK : fatal error C1007: unrecognized flag '-Ot' in 'p2'
I've read questions on what the cause could be, but I couldn't come to a solution for my project.
The details are that, due to an external component we have no control over (component A), this Visual Studio 2017 project is forced to use the v14.13 version of the C++ toolchain, i.e. not the latest one (v14.14). However, the latest release of another external precompiled static lib we have no control over either (component B), is built with the v14.14 version (I checked via a dumpbin extract of the debug version of the lib). Switching my project over to the v14.14 toolchain indeed makes the link error go away on component B, but this unfortunately isn't a solution for me due to component A. Taking an earlier version of component B isn't desirable either, since we need the functionality in the latest release...
However, what strikes me, is that the /Ot ("optimize for speed") flag has been around since the middle ages... Why wouldn't v14.13 recognize it? Or is it just an (awkwardly manifested) matter of a mismatched obj file layout due to the version differences? And, probably related, what does the 'p2' stand for anyway?
Update
I've checked the linker output by using the /verbose flag, and all seems normal (3600 lines of Searching <lib>, Found <function>, Referenced in <obj> and Loaded <lib>).
Right up until the end that is, where I get the following 6 lines:
1> Searching C:\PathToExternalLib\TheirStatic.lib:
1> Found UsedFunctionName
1> Referenced in MyOwnStatic.lib(MyOwnCompileUnit.obj)
1>LINK : fatal error C1007: unrecognized flag '-Ot' in 'p2'
1>LINK : fatal error LNK1257: code generation failed
1>Done building project "MyProject.vcxproj" -- FAILED.
And that's that.
When visiting the command line setting of the link properties of the project, the only thing listed is (broken up in separate lines for convenience):
/OUT:"MyProject.dll"
/MANIFEST
/NXCOMPAT
/PDB:"MyProject.pdb"
/DYNAMICBASE "C:\PathToMyStatic.lib"
/IMPLIB:"MyProject.lib"
/DLL
/MACHINE:X64
/PGD:"MyProject.pgd"
/MANIFESTUAC:"level='asInvoker' uiAccess='false'"
/ManifestFile:"MyProject.prm.intermediate.manifest"
/ERRORREPORT:PROMPT
/NOLOGO
/LIBPATH:"C:\PathToExternalStaticLib"
/LIBPATH:"C:\PathToAnotherExternalStaticLib"
/TLBID:1
So no trace of any -Ot flag there as well...?
I had this problem. LINK : fatal error C1007: unrecognized flag '-Ot' in 'p2'
while building a project with Visual Studio 2015.
I had to rebuild any library or sub library the project linked to which were built with Visual Studio 2017.
Once I rebuild the dependent libraries with Visual Studio 2015 the first project was able to link against them.
project
--------\
---------lib1(unable to rebuild lib1 until its dependencies were also rebuilt with VS2015
--------------\lib_linked_by_lib1_which_was_build_with_VS2017_and_had_to_be_rebuilt
--------------\another_lib_which_had_to_be_rebuilt_for_lib1_with_VS2015
--------\lib2
--------\lib3
Version 0.7.+'s of the gradle plugin includes preliminary ndk support. I worked off the examples but I get a compilation error when trying to include a standard NDK header:
In file included from /foo/src/main/jni/Bar.h:4:0,
from /foo/src/main/jni/Bar.cpp:1:
/foo/src/main/jni/baz.h:4:25: fatal error: android/log.h: No such file or directory
compilation terminated.
Where baz.h has this line:
#include <android/log.h>
And my gradle file has:
ndk {
ldLibs "log"
}
Has anyone made this work?
shouldn't it be ldLibs "-llog" ?
P.S.
NDK support is very unstable now... I was fighting with it for a few days - it completely broken on Windows. No easy way to disable it (but still possible). On some circumstances build process will generate wrong file path (like /foo/bar//foo/bar/source.c). So we switched back to the 0.6.+ version and monitoring https://code.google.com/p/android/issues/list?q=tools%40android.com
I am trying to use mupdf in android application.I am using windows 7 and cygwin terminal.I used make but it gave error and
make NOX11=yes
execute successfully.
then i used ndk-build and it gives this error.
SharedLibrary : libmupdf.so
c:/android-ndk-r8b/toolchains/arm-linux-androideabi-4.6/prebuilt/windows/bin/../lib/gcc/arm-linux-androideabi/4.6.x-google/../../../../arm-linux-androideabi/bin/ld.exe: ./obj/local/armeabi/libmupdfcore.a(pdf_fontfile.o)(.text.pdf_lookup_builtin_font+0x18): unresolvable R_ARM_THM_CALL relocation against symbol `strcmp'
c:/android-ndk-r8b/toolchains/arm-linux-androideabi-4.6/prebuilt/windows/bin/../lib/gcc/arm-linux-androideabi/4.6.x-google/../../../../arm-linux-androideabi/bin/ld.exe: final link failed: Nonrepresentable section on output
collect2: ld returned 1 exit status
/cygdrive/c/android-ndk-r8b/build/core/build-binary.mk:378: recipe for target `obj/local/armeabi/libmupdf.so' failed
make: *** [obj/local/armeabi/libmupdf.so] Error 1
please help me.I am new to android ndk.
Thank you.
This seems like a known issue. Try adding the line:
NDK_TOOLCHAIN_VERSION=4.4.3
to the file ..\android\jin\Application.mk. That will at least get rid of this particular error.
EDIT: Look here http://code.google.com/p/android/issues/detail?id=35393 for more information
UPDATE:
mupdf world is a murky one. Even the version of NDK vis-a-vis the version of mupdf (http://mupdf.com/download/archive/) you use will determine what sort of errors or warnings you get. From my experience, mupdf-0.9 (+mupdf-thirdparty-2011-02-24.zip) behaves well with android-ndk-r6b, while mupdf-1.1 (+mupdf-thirdparty-2012-08-14.zip) will behave just fine with android-ndk-r8b.
I've been having issues with compiling pjsip for iOS 4.0.
I am using the latest trunk version from SVN and keep getting a portaudio error. When using the piedmontwireless guide: http://www.piemontewireless.net/PJSip155_and_iPhoneSDK312 I get a missing separator error in my build.mak file, which would indicate a whitespace/tabbing error, but for the life of me I cannot find it.
According to the pjsip mailing lists, you should be able to compile out of the box for iOS 4.0, but I get this error:
../src/pjmedia-audiodev/errno.c:23:26: error: portaudio.h: No such file or directory
../src/pjmedia-audiodev/errno.c: In function ‘pjmedia_audiodev_strerror’:
../src/pjmedia-audiodev/errno.c:104: warning: implicit declaration of function ‘Pa_GetErrorText’
make[2]: *** [output/pjmedia-audiodev-arm-apple-darwin9/errno.o] Error 1
make[1]: *** [pjmedia-audiodev] Error 2
I'll keep punching through this but any help would be really appreciated.
EDIT: I do have portaudio.h
The specific step you are missing is to have a config_site.h file in the proper location.
pjlib/include/pj/config_site.h
It needs to contain the following:
#define PJ_CONFIG_IPHONE 1
#include <pj/config_site_sample.h>
So the configuration will avoid libraries that are not needed or won't compile for the arm chip in the iPhone.
After this addition start over with:
./configure-iphone
and then
make dep && make clean && make
./configure-iphone
Fresh from SVN
Configurations for current target have been written to 'build.mak', and 'os-auto.mak' in various build directories, and pjlib/include/pj/compat/os_auto.h.
Further customizations can be put in:
- 'user.mak'
- 'pjlib/include/pj/config_site.h'
The next step now is to run 'make dep' and 'make'.
Done configuring for iPhoneOS4.2.sdk
Shouldn't ./configure-iphone setup pjlib/include/pj/config_site.h
As
#define PJ_CONFIG_IPHONE 1
#include <pj/config_site_sample.h>
Thanks for the fix #Schroedinger
hey all, I just installed VC 2010 Premium Beta2 on my system and I migrated my old vc9 projects to it... everything seemed ok at first...
what's strange is that no matter what I compile I get the following error message:
1> Microsoft (R) Incremental Linker Version 6.00.8447
1> Copyright (C) Microsoft Corp 1992-1998. All rights reserved.
1>
1> ■/
1>LINK : warning LNK4044: unrecognized option "ERRORREPORT:PROMPT"; ignored
1>LINK : fatal error LNK1181: cannot open input file " ■/.obj"
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
the warning about errorreport is a little annoying but non-fatal... annoying because no matter which errorreport setting I choose, the warning stays... however the LNK1181 is fatal and even more frustrating because it seems to have no detectable cause.
my input list contains no .obj files, only various .lib files... furthermore, there is that strange block-like special ascii character in the name which I've certainly never typed anywhere. initially when this showed up I thought it must be some artifact of the vc9 to vc10 migration... and after spending 2 hours looking all over for the cause, it occurred to me to test whether or not it occurs with brand new projects... well sure enough it does!!
I create a BRAND NEW project... involving no migration, nada... just a brand new win32 project with the default afx files and so forth... I don't change any default setting and it gets this exact same linker error!
I hope somebody here can shed some light because this is very mysterious... at the moment the only other diagnostic method I can think of is to try to create a new workspace and add a new project to that and see if that works... ok just tried that and no dice... problem still persists.
anybody have some advice or seen this before?
You have an old copy of your pre-processor or linker (cl.exe, link.exe) in your system path.