Ask Your Question

kmhofmann's profile - activity

2015-11-05 10:25:23 -0600 asked a question Unclear integration into Android.mk / building from source

I am attempting to integrate OpenCV into the Android.mk file of one of my projects and am running into severe difficulties there.

Our build policies mandate that all external libraries are to be built from source. Besides, it's good practice to do so. In any case, I would naively expect to have to do something along the lines of the following steps:

  1. clone the OpenCV repository (in my case git clone https://github.com/Itseez/opencv.git 3.0.0, or alternatively using tag 2.4.11),
  2. locate a maintained Android.mk file that I can reference from my Android.mk,
  3. call ndk-build using my own Android.mk.
  4. The architectures to build (as well as the standard library to use) are then determined by the contents of my Application.mk.

This seems to be not the case, as I could not find a suitable Android.mk file in the source distribution. The official documentation refers to an OpenCV.mk file which simply does not exist in this source distribution. Also, the include directories seem to be scattered around the module directories, making it difficult to refer to exactly one base include directory. (This seems to be a questionable design decision.)

There appears to be an official "SDK" for Android, which only distributes some binary files, i.e. that is not a complete source distribution. It is unclear to me how to build exactly this SDK distribution from the source distribution.

I have found this unmaintained page ("Building OpenCV4Android from trunk"), which seems to explain exactly this step, and I can successfully complete all the steps described there in the section 'Linux (Ubuntu) and Mac OS (10.6.7)'. But:

  • the resulting build_android_arm directory is far from identical with the downloadable "SDK" distribution;
  • it seems that only libraries for armeabi-v7a are being built (I need armeabi-v7a-hard, armv8, x86 and x86_64)
  • there is still no ready-to-use include directory.

My questions are the following:

  1. How can I build OpenCV static libraries for all my required architectures, without resorting to hacks like string changes in the CMake cache?
  2. How can I get a distribution-ready include directory?
  3. After solving 1. and 2., is the generated OpenCV.mk file inside the build_android_arm folder ready to use? Does it apply to all build architectures?

Thanks for any help!

2014-10-15 07:00:35 -0600 received badge  Student (source)
2014-10-15 03:27:24 -0600 asked a question Android.mk: problems selectively integrating OpenCV modules

I’m having issues installing the prebuilt OpenCV libraries for Android.

I have followed the documentation, and can properly install the prebuilt shared library like this: (see http://docs.opencv.org/doc/tutorials/introduction/android_binary_package/dev_with_OCV_on_Android.html#native-c)

include $(CLEAR_VARS)
LOCAL_MODULE := MyLibStatic
LOCAL_SRC_FILES := #… (files that use OpenCV)
# also set LOCAL_CPPFLAGS, LOCAL_C_INCLUDES , etc.
include $(BUILD_STATIC_LIBRARY)

#---

include $(CLEAR_VARS)

OPENCV_INSTALL_MODULES:=on
OPENCV_CAMERA_MODULES:=off
#OPENCV_LIB_TYPE:=STATIC
include $(MY_OPENCV_INCPATH)/../OpenCV.mk

LOCAL_MODULE := MyLib
LOCAL_SRC_FILES += #… (files that use OpenCV)
LOCAL_STATIC_LIBRARIES := MyLibStatic
# also set LOCAL_CPPFLAGS, LOCAL_C_INCLUDES, LOCAL_LDLIBS, etc.
include $(BUILD_SHARED_LIBRARY)

However, the issue with this way of integrating is a conflict between the libjpeg version we’re statically compiling into our project (version 9), and the version of libjpeg that’s included in the highgui library (seems to be version 8). At runtime, the OpenCV-included symbols seem to be called, which does not match the version in our header:

E/Debug (26553): libjpeg error: Wrong JPEG library version: library is 90, caller expects 80

Bummer. The obvious (and preferred) solution is to statically link only the parts of OpenCV that we actually need (core, features2d, calib3d, imgproc), via the provided .a files, and to leave away everything else that might lead to conflicts or bloat the resulting APK. However, this is where I run into issues.

First attempt: Just try to link everything statically, by uncommenting the above “OPENCV_LIB_TYPE:=STATIC” line. I would then still have to change the OpenCV.mk file by removing all references to libjpeg (and other unneeded libraries). However, just uncommenting the line leads to a multitude of linker errors when recompiling with ndk-build.

../../OpenCV-2.4.9-android-sdk/sdk/native/jni/include/opencv2/core/mat.hpp:278: error: undefined reference to 'cv::fastFree(void*)'
../../OpenCV-2.4.9-android-sdk/sdk/native/jni/include/opencv2/core/mat.hpp:367: error: undefined reference to 'cv::Mat::deallocate()'
…
… # a lot more errors

Shouldn’t this “just work” (according to the documentation, where no additional steps are mentioned)? It seems that the OpenCV.mk makefile should include them as prebuilt static binaries.

Second attempt: Include the prebuilt libraries manually. This would be my preferred way, but seems to be thoroughly undocumented. Instead of including the OpenCV.mk file, I added the following sections to my makefile (assume that MY_OPENCV_LIBPATH and MY_OPENCV_EXT_LIBPATH are set to point to the respective directory with the .a files):

include $(CLEAR_VARS)
LOCAL_MODULE := local_opencv_tbb
LOCAL_SRC_FILES := $(MY_OPENCV_EXT_LIBPATH)/libtbb.a
include $(PREBUILT_STATIC_LIBRARY)

include $(CLEAR_VARS)
LOCAL_MODULE := local_opencv_core
LOCAL_SRC_FILES := $(MY_OPENCV_LIBPATH)/libopencv_core.a
include $(PREBUILT_STATIC_LIBRARY)

include $(CLEAR_VARS)
LOCAL_MODULE := local_opencv_features2d
LOCAL_SRC_FILES := $(MY_OPENCV_LIBPATH)/libopencv_features2d.a
include $(PREBUILT_STATIC_LIBRARY)

include $(CLEAR_VARS)
LOCAL_MODULE := local_opencv_calib3d
LOCAL_SRC_FILES := $(MY_OPENCV_LIBPATH)/libopencv_calib3d.a
include $(PREBUILT_STATIC_LIBRARY)

include $(CLEAR_VARS)
LOCAL_MODULE := local_opencv_imgproc
LOCAL_SRC_FILES := $(MY_OPENCV_LIBPATH)/libopencv_imgproc.a
include $(PREBUILT_STATIC_LIBRARY)

and then, in the section of the MyLib module, added the following:

LOCAL_STATIC_LIBRARIES += local_opencv_tdd local_opencv_core local_opencv_features2d local_opencv_calib3d local_opencv_imgproc

If I understood the OpenCV makefile correctly, this should roughly mimic what the makefile achieves when included via "include OpenCV.mk". Again, this does lead to lots of linker errors. I cannot even see the prebuilt libraries being generated in the ./obj or ./lib folders of my project.

Who ... (more)

2014-05-06 07:06:44 -0600 asked a question Compiler error using GCC 4.8.2 (MacPorts), OS X 10.9.2

I'm trying to build OpenCV 2.4.9 from source on Mac OS X 10.9.2, using GCC 4.8.2 from MacPorts. Unfortunately I'm getting compile errors when trying to build the highgui module.

I'm attaching the CMake output as well as the error messages. It was suggested here to disable QuickTime support (-D WITH_QUICKTIME=OFF) for a similar-looking error, however that doesn't seem to help.

Can someone reproduce this behavior (I'd assume quite a few users must have experience this?) and let me know how to fix the build process? Thanks!

opencv-2.4.9-build$ which gcc
/opt/local/bin/gcc
opencv-2.4.9-build$ gcc --version
gcc (MacPorts gcc48 4.8.2_0) 4.8.2
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
opencv-2.4.9-build$ cmake -DWITH_QUICKTIME=OFF ../opencv-2.4.9
-- The CXX compiler identification is GNU 4.8.2
-- The C compiler identification is GNU 4.8.2
-- Checking whether CXX compiler has -isysroot
-- Checking whether CXX compiler has -isysroot - yes
-- Checking whether CXX compiler supports OSX deployment target flag
-- Checking whether CXX compiler supports OSX deployment target flag - yes
-- Check for working CXX compiler: /opt/local/bin/c++
-- Check for working CXX compiler: /opt/local/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Checking whether C compiler has -isysroot
-- Checking whether C compiler has -isysroot - yes
-- Checking whether C compiler supports OSX deployment target flag
-- Checking whether C compiler supports OSX deployment target flag - yes
-- Check for working C compiler: /opt/local/bin/gcc
-- Check for working C compiler: /opt/local/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detected version of GNU GCC: 48 (408)
-- Performing Test HAVE_CXX_FSIGNED_CHAR
-- Performing Test HAVE_CXX_FSIGNED_CHAR - Success
-- Performing Test HAVE_C_FSIGNED_CHAR
-- Performing Test HAVE_C_FSIGNED_CHAR - Success
-- Performing Test HAVE_CXX_W
-- Performing Test HAVE_CXX_W - Success
-- Performing Test HAVE_C_W
-- Performing Test HAVE_C_W - Success
-- Performing Test HAVE_CXX_WALL
-- Performing Test HAVE_CXX_WALL - Success
-- Performing Test HAVE_C_WALL
-- Performing Test HAVE_C_WALL - Success
-- Performing Test HAVE_CXX_WERROR_RETURN_TYPE
-- Performing Test HAVE_CXX_WERROR_RETURN_TYPE - Success
-- Performing Test HAVE_C_WERROR_RETURN_TYPE
-- Performing Test HAVE_C_WERROR_RETURN_TYPE - Success
-- Performing Test HAVE_CXX_WERROR_ADDRESS
-- Performing Test HAVE_CXX_WERROR_ADDRESS - Success
-- Performing Test HAVE_C_WERROR_ADDRESS
-- Performing Test HAVE_C_WERROR_ADDRESS - Success
-- Performing Test HAVE_CXX_WERROR_SEQUENCE_POINT
-- Performing Test HAVE_CXX_WERROR_SEQUENCE_POINT - Success
-- Performing Test HAVE_C_WERROR_SEQUENCE_POINT
-- Performing Test HAVE_C_WERROR_SEQUENCE_POINT - Success
-- Performing Test HAVE_CXX_WFORMAT
-- Performing Test HAVE_CXX_WFORMAT - Success
-- Performing Test HAVE_C_WFORMAT
-- Performing Test HAVE_C_WFORMAT - Success
-- Performing Test HAVE_CXX_WERROR_FORMAT_SECURITY
-- Performing Test HAVE_CXX_WERROR_FORMAT_SECURITY - Success
-- Performing Test HAVE_C_WERROR_FORMAT_SECURITY
-- Performing Test HAVE_C_WERROR_FORMAT_SECURITY - Success
-- Performing Test HAVE_CXX_WMISSING_DECLARATIONS
-- Performing Test HAVE_CXX_WMISSING_DECLARATIONS - Success
-- Performing Test HAVE_C_WMISSING_DECLARATIONS
-- Performing Test HAVE_C_WMISSING_DECLARATIONS - Success
-- Performing Test HAVE_CXX_WMISSING_PROTOTYPES
-- Performing Test HAVE_CXX_WMISSING_PROTOTYPES - Failed
-- Performing Test HAVE_C_WMISSING_PROTOTYPES
-- Performing Test HAVE_C_WMISSING_PROTOTYPES - Success
-- Performing Test HAVE_CXX_WSTRICT_PROTOTYPES
-- Performing Test HAVE_CXX_WSTRICT_PROTOTYPES - Failed
-- Performing Test HAVE_C_WSTRICT_PROTOTYPES
-- Performing Test HAVE_C_WSTRICT_PROTOTYPES - Success
-- Performing Test HAVE_CXX_WUNDEF
-- Performing Test HAVE_CXX_WUNDEF - Success
-- Performing Test HAVE_C_WUNDEF
-- Performing Test HAVE_C_WUNDEF - Success
-- Performing Test HAVE_CXX_WINIT_SELF
-- Performing Test HAVE_CXX_WINIT_SELF - Success
-- Performing Test HAVE_C_WINIT_SELF
-- Performing Test HAVE_C_WINIT_SELF - Success
-- Performing Test HAVE_CXX_WPOINTER_ARITH
-- Performing Test HAVE_CXX_WPOINTER_ARITH - Success ...
(more)