I want to transplant the VXL(the Vision-something-Libraries) to android platform.the crosscompiler I used is android-cmake.
you can get the VXL from the url http://vxl.sourceforge.net/ .the version i used is vxl-1.14.0
you can get the android-camke from the url http://code.google.com/p/android-cmake/
when I properly setup my NDK for cmake,and specify the Standalone Toolchain as the introduction of android-camke.Then,I use andriod-camke to compile the VXL.But I encounter many error.it can't produce the Makefile . somebody know why?
Next is the error log.
l00138375#l00138375:/home/hm/build-vxl$ android-cmake ../vxl-1.14.0
CMake Warning at /home/hm/android/android-cmake/toolchain/android.toolchain.cmake:281 (message):
Using value of obsolete variable ANDROID_NDK_TOOLCHAIN_ROOT as initial
value for ANDROID_STANDALONE_TOOLCHAIN. Please note, that
ANDROID_NDK_TOOLCHAIN_ROOT can be completely removed in future versions of
the toolchain.
Call Stack (most recent call first):
/home/hm/android/android-cmake/toolchain/android.toolchain.cmake:376 (__INIT_VARIABLE)
/usr/share/cmake-2.8/Modules/CMakeDetermineSystem.cmake:89 (INCLUDE)
CMakeLists.txt:13 (PROJECT)
........
-- Check if the system is big endian - little endian
-- Performing Test VCL_CHAR_IS_SIGNED
CMake Error: TRY_RUN() invoked in cross-compiling mode, please set the following cache variables appropriately:
VCL_CHAR_IS_SIGNED (advanced)
VCL_CHAR_IS_SIGNED__TRYRUN_OUTPUT (advanced)
For details see /home/hm/build-vxl/TryRunResults.cmake
-- Performing Test VCL_CHAR_IS_SIGNED - Failed
-- Looking for 8-bit int. [Checking char...]
CMake Error: TRY_RUN() invoked in cross-compiling mode, please set the following cache variables appropriately:
RUN_RESULT (advanced)
RUN_RESULT__TRYRUN_OUTPUT (advanced)
For details see /home/hm/build-vxl/TryRunResults.cmake
.........
-- Performing Test VCL_NUMERIC_LIMITS_HAS_INFINITY
CMake Error: TRY_RUN() invoked in cross-compiling mode, please set the following cache variables appropriately:
VCL_NUMERIC_LIMITS_HAS_INFINITY (advanced)
VCL_NUMERIC_LIMITS_HAS_INFINITY__TRYRUN_OUTPUT (advanced)
For details see /home/hm/build-vxl/TryRunResults.cmake
-- Performing Test VCL_NUMERIC_LIMITS_HAS_INFINITY - Failed
-- Performing Test VCL_PROCESSOR_HAS_INFINITY
CMake Error: TRY_RUN() invoked in cross-compiling mode, please set the following cache variables appropriately:
VCL_PROCESSOR_HAS_INFINITY (advanced)
VCL_PROCESSOR_HAS_INFINITY__TRYRUN_OUTPUT (advanced)
For details see /home/hm/build-vxl/TryRunResults.cmake
-- Performing Test VCL_PROCESSOR_HAS_INFINITY - Failed
-- Looking for C++ include inttypes.h
-- Looking for C++ include inttypes.h - found
-- Looking for memalign
-- Looking for memalign - found
-- Could NOT find DC1394 (missing: DC1394_LIBRARIES DC1394_INCLUDE_DIR)
-- Performing Test DIRECTSHOW_SOURCE_COMPILES
-- Performing Test DIRECTSHOW_SOURCE_COMPILES - Failed
CMake Error at config/cmake/Modules/NewCMake/FindDirectShow.cmake:101 (MESSAGE):
Uncomment code below: FindPackageHandleStandardArgs is now available.
Call Stack (most recent call first):
core/vidl/CMakeLists.txt:13 (INCLUDE)
As Andrey's comment mentions, the way VXL uses CMake, prevents cross-compilation. However there is an alternative. One of the maintainers maintains branches containing alternative build systems for the core libraries. The vxl-build-makefiles branch ought to be a good starting point to modify to work with a cross-compiler.
http://sourceforge.net/p/vxl/svn/36716/tree/branches/vxl-build-makefiles/
If you have any questions about using the branch, or indeed anything else about VXL - the vxl mailing lists are probably more use. vxl-users#lists.sourceforge.net
Related
First time android builder here. I used to do a lot of roll your own back on FreeBSD in the day. Getting back into geekdom with android.
I am trying to build android-7.0.0_r14 for the Nexus 6 NBD90Z to run under emulation. I plan to eventually build for my actual phone and this config is pretty close. I am building on ubuntu 18.04 LTS which is newer than what the docs recommend. Maybe that is a bit adventurous.
Here is what I get when I run make.
... snip
build/core/base_rules.mk:316: warning: ignoring old commands for target
out/target/product/shamu/system/lib/soundfx/libqcomvoiceprocessing.so'
Starting build with ninja
ninja: Entering directory.'
ninja: warning: multiple rules generate out/target/product/shamu/system/etc/gps.conf. builds involving this target will not be correct; continuing anyway [-w dupbuild=warn]
[ 0% 1/35600] Lex: libaidl-common <= system/tools/aidl/aidl_language_l.ll
FAILED: /bin/bash -c "prebuilts/misc/linux-x86/flex/flex-2.5.39 -oout/host/linux-x86/obj/STATIC_LIBRARIES/libaidl-common_intermediates/aidl_language_l.cpp system/tools/aidl/aidl_language_l.ll"
flex-2.5.39: loadlocale.c:130: _nl_intern_locale_data: Assertion `cnt < (sizeof (_nl_value_type_LC_TIME) / sizeof (_nl_value_type_LC_TIME[0]))' failed.
Aborted (core dumped)
ninja: build stopped: subcommand failed.
build/core/ninja.mk:148: recipe for target 'ninja_wrapper' failed
make: *** [ninja_wrapper] Error 1
A core dump for flex was not produced in spite of the error message given.
out/host/linux-x86/obj/STATIC_LIBRARIES/libaidl-common_intermediates/aidl_language_l.cpp does not exist. That entire folder is empty. It would seem that something is not downloading/copying the aidl_language_l.cpp.
Any ideas on what I might have messed up?
I am still a little confused at the complexity of git/repo/make/ninja/soong/lunch to conduct a build. It is likely that I missed something obvious.
Thanks,
Jason C. Wells
Just replace your make by export LC_ALL=C make or put the export in your .bashrc
After I looked at this a little closer I realized the prebuilt prebuilts/misc/linux-x86/flex/flex-2.5.39 would dump core with no arguments. I created a soft link to /usr/bin/flex. Compilation seems to be proceeding.
I haven't answered why the prebuilt was dumping. My goal is to compile android, not troubleshoot the tools.
I performed Snorky's steps. I deleted my output directory for libaidl-common_intermediates. I deleted my soft link and restored the android tree version of flex. I re-ran make at the top of the local repo. The build proceeded past the error above and stopped at a new error. It appears that Snorky's answer worked.
Doh! I'm new so S.O. didn't give credit for my upvote.
I've built the iOS version of my app about a month or so ago. Then added a few extra messages to the UI, tested with the Android version and now when I rebuild the iOS version it seems to fail. The error log is at: https://s3.amazonaws.com/codenameone-build-response/621a8710-2900-45a3-afdb-e3a30bdb1265-1504680431641-error.txt
At the bottom of this, the only actual failure I see is:
** ARCHIVE FAILED **
The following build commands failed:
CompileC build/Build/Intermediates/ArchiveIntermediates/MyApplication/IntermediateBuildFilesPath/MyApplication.build/Release-iphoneos/MyApplication.build/Objects-normal/arm64/com_codename1_io_websocket_WebSocketNativeImplImpl.o MyApplication-src/com_codename1_io_websocket_WebSocketNativeImplImpl.m normal arm64 objective-c com.apple.compilers.llvm.clang.1_0.compiler
(1 failure)
Failed xcodebuild step
I have updated the CN1Libs a few days ago. Not really sure what about this is actually failing to build.
Notice that the file com_codename1_io_websocket_WebSocketNativeImplImpl.m is mentioned in the final lines which means that's the file that failed. If you search the file for mentions of com_codename1_io_websocket_WebSocketNativeImplImpl.m you will find:
src/com_codename1_io_websocket_WebSocketNativeImplImpl.m -o /var/folders/zh/kb_4hqhn4kg1h0r5dp_6htcm0000gn/T/build7085253492970683151xxx/dist/build/Build/Intermediates/ArchiveIntermediates/MyApplication/IntermediateBuildFilesPath/MyApplication.build/Release-iphoneos/MyApplication.build/Objects-normal/arm64/com_codename1_io_websocket_WebSocketNativeImplImpl.o
/var/folders/zh/kb_4hqhn4kg1h0r5dp_6htcm0000gn/T/build7085253492970683151xxx/dist/MyApplication-src/com_codename1_io_websocket_WebSocketNativeImplImpl.m:23:9: fatal error: 'com_codename1_io_websocket_WebSocket.h' file not found
#import "com_codename1_io_websocket_WebSocket.h"
^
1 error generated.
This might be a bit confusing but it generally means you added the cn1lib for websockets and didn't use it. That's a problem as our VM strips out unused code but the websockets cn1lib needs to include the callback interface which is now stripped away.
Currently trying to build android-5.1.0_r5. I've checked out the sources and made no modifications. However, when compiling I get the following error.
Checking API: checkpublicapi-current
out/target/common/obj/PACKAGING/public_api.txt:20: error 5: Added public field android.Manifest.permission.BACKUP
out/target/common/obj/PACKAGING/public_api.txt:82: error 5: Added public field android.Manifest.permission.INVOKE_CARRIER_SETUP
out/target/common/obj/PACKAGING/public_api.txt:106: error 5: Added public field android.Manifest.permission.READ_PRIVILEGED_PHONE_STATE
out/target/common/obj/PACKAGING/public_api.txt:116: error 5: Added public field android.Manifest.permission.RECEIVE_EMERGENCY_BROADCAST
******************************
You have tried to change the API from what has been previously approved.
To make these errors go away, you have two choices:
1) You can add "#hide" javadoc comments to the methods, etc. listed in the
errors above.
2) You can update current.txt by executing the following command:
make update-api
To submit the revised current.txt to the main Android repository,
you will need approval.
******************************
And diffing the public api txt files does indeed show a difference.
diff frameworks/base/api/current.txt out/target/common/obj/PACKAGING/public_api.txt
19a20
> field public static final java.lang.String BACKUP = "android.permission.BACKUP";
80a82
> field public static final java.lang.String INVOKE_CARRIER_SETUP = "android.permission.INVOKE_CARRIER_SETUP";
103a106
> field public static final java.lang.String READ_PRIVILEGED_PHONE_STATE = "android.permission.READ_PRIVILEGED_PHONE_STATE";
112a116
> field public static final java.lang.String RECEIVE_EMERGENCY_BROADCAST = "android.permission.RECEIVE_EMERGENCY_BROADCAST";
However, I cant figure out where those additional Public Fields are coming from. Any ideas?
Don't do 'make update-api' if you didn't touch anything. There additional apis came form frameworks/base/res/AndroidManifest.xml badly parsed by aapt that uses buggy system/core/libcore/String8.cpp##removeAll() they use memcpy but should be memmove for overlapping strings in memory.
This is issue on latest Debian (sid) or Ubuntu (16 maybe 15) build machines.
It's a google bug in libcore/String8.cpp. Fix is here:
https://android.googlesource.com/platform/system/core/+/dd060f01f68ee0e633e9cae24c4e565cda2032bd
This man found it (Michael Scott) and maybe some other people too. Here is his investigation: https://plus.google.com/+hashcode0f/posts/URHo3hBmfHY
Living on the Edge (of Ubuntu) ... can be painful!
I've been running Ubuntu 15.04 for a while now. It's been great
having a very current kernel alongside the latest improvements from
Ubuntu and Debian. (My past post on using zRAM ramdisk is one
example).
However, having the newest greatest toys also has it's downsides. I
recently spent 4 days troubleshooting a build break in Android which
started some time after March 25th. I'm guessing I updated packages
or inadvertently changed my glibc version.
The outcome was a build error during the checkapi stage of Android
build:
Install: /out/mydroid-ara/host/linux-x86/bin/apicheck Checking API:
checkpublicapi-last Checking API: checkpublicapi-current
/out/mydroid-ara/target/common/obj/PACKAGING/public_api.txt:20: error
5: Added public field android.Manifest.permission.BACKUP
/out/mydroid-ara/target/common/obj/PACKAGING/public_api.txt:82: error
5: Added public field android.Manifest.permission.INVOKE_CARRIER_SETUP
/out/mydroid-ara/target/common/obj/PACKAGING/public_api.txt:106: error
5: Added public field
android.Manifest.permission.READ_PRIVILEGED_PHONE_STATE
/out/mydroid-ara/target/common/obj/PACKAGING/public_api.txt:116: error
5: Added public field
android.Manifest.permission.RECEIVE_EMERGENCY_BROADCAST
**************************** You have tried to change the API from what has been previously approved.
To make these errors go away, you have two choices: 1) You can add
"#hide" javadoc comments to the methods, etc. listed in the
errors above.
2) You can update current.txt by executing the following command:
make update-api
To submit the revised current.txt to the main Android repository,
you will need approval.
This occurred on both of my Ubuntu 15.04 boxes and was present when
when build AOSP android-5.0.2_r1 and android-5.1.0_r1.
For those of you who are unfamiliar with this portion of the Android
build, the Android framework exports all of the public portions of the
API and makes sure that the current build matches up with what's
located under frameworks/base/api/current.txt. It does this by
parsing frameworks/base/res/AndroidManifest.xml and any of the current
device's overlay .xml files and processes items marked with various
flags in the comments above them:#SystemApi, #hide, etc. This
parsing and processing portion of the checkapi stage is done by a
binary "aapt" (Android Asset Packagng Tool). It's source is located
under frameworks/base/tools/aapt.
I started by checking for upstream fixes to the platform/build or
platform/frameworks/base projects. After striking out, I began
debugging the android build via the use of: "make checkapi
showcommands" and then manually running the commands with "strace" to
see how each binary was involved and what output it generated.
After the first few hours of debugging, it became apparent that
out/target/common/obj/APPS/frameworks-res_intermediates/src/android/Manifest.java
file had comments which were being corrupted when aapt was generating
it. I was able to make some manual changes to the AndroidManifest.xml
file and get the build to pass (removing extra portions of the
comments).
Digging deeper via strace and then looking at various static link
sources, I found that during the AndroidManifest.xml comments
processing the #SystemApi token was being filtered out via a
String8.removeAll("#SystemApi") function call. Experimentally, I
removed this part of the processing. Lo and Behold! The build
worked. Taking a closer look at the removeAll function, I was able to
pin point a memcpy function as the part of the function which was
causing corruption.
I then researched memcpy a bit and noted that you are not supposed to
use memcpy on overlapping memory addresses, instead memmove was
preferred, because it makes a copy of the source prior to any changes
being made to the destination. After changing the use of memcpy to
memmove the build was fixed and all was well with the world!
As a good player in the open source world, I immediately thought I
should upstream this incredible feat of debugging to the master branch
of system/core. BUT, alas! The fix has been in the master branch
since November 11th 2014! And hasn't been brought into any of the
current development tags! grumble
https://android.googlesource.com/platform/system/core/+/dd060f01f68ee0e633e9cae24c4e565cda2032bd
I've since contacted the Google team about this change and let them
know of my experience in hopes that we may yet see this patch in
future release tags of Android.
Conclusion: apparently glibc is undergoeing some changes and some of
those have now filtered onto my Ubuntu boxes. Where previously the
memcpy usage was incorrect but still usable, it now causes the build
break I was seeing.
If you see this kind of error in your Android builds, and you're on a
newish version of Ubuntu or Debian distrobution, you may want to try
this simple patch and see if it helps.
Hash
Big up himself!
I do see the entries in my r8 code so you are probably safe running make update-api, and when that finishes then run your make command as normal.
I am trying to debug native code on Android using ndk-gdb, with mixed results.
When the debugger hits a breakpoint, I am able to get a nice stack trace using 'bt'.
Hhen typing 'info source', ndk-gdb tells me that the file I have hit the breakpoint in is "Compiled with DWARF 2 debugging format".
The problem arises when I enter 'info args' to get the function argument values. ndk-gdb then states that: "No symbol table info available.".
Any input to the cause of this problem would be appreciated.
It's strange that it says that about the file being compiled with DWARF 2 format, because the flags you provide there indicates it is only specifying -g, which should get GCC 4.8 to produce DWARF 4 format. Which also is consistent with the error you are seeing. Add the flag -gdwarf-2 and the NDK debugger (which is not yet at version 7.5) should be able to deal with the symbols.
I picked this up from one of the answers to this question: Debugging with gdb on a program with no optimization but still there is no symbol in the current context for local variables
I'm currently building an android application using ANT on a Jenkins server.
DexGuard is set to run on release in the custom_rules.xml.
Currently there is an issue when DexGuard tries to convert a method:
[dexguard] Unexpected error while converting:
[dexguard] Class = [o/?]
[dexguard] Method = [?(Ljava/lang/String;)Lo/?;]
[dexguard] Exception = [java.lang.IllegalStateException] (Variable v17 too large for instruction [neg-int v17, v17])
[dexguard] java.lang.IllegalStateException: Variable v17 too large for instruction [neg-int v17, v17]
...
Stack trace
...
[dexguard] Not converting this method
My question is, is there a way to get DexGuard to exit with an error status so that either ANT or Jenkins can mark the build as failed?
At the moment it simply prints the stack trace and continues.
I am currently using the Text-finder plugin for Jenkins as a post build step to match a DexGuard exception. If found it downgrades the build to failed.
DexGuard currently ignores methods that it can't convert from Java bytecode to Dalvik bytecode, for any reason -- notably corrupt input code. In this case, it looks more like a bug in DexGuard itself. We'll fix it as soon as possible, and we'll consider adding a flag to stop with an error status.
(I am the lead developer of ProGuard and DexGuard)