- removed OpenCV_LIB_DIR* vars (they are broken and not required anymore)
- OpenCVConfig.cmake doesn't contain ANDROID/CUDA code if there is no such support
- removed OpenCV2_INCLUDE_DIRS_CONFIGCMAKE, merged into OpenCV_INCLUDE_DIRS_CONFIGCMAKE
- fix hard-coded relative paths for OpenCV_INSTALL_PATH
- removed OpenCV_TBB_ARCH
- switch OpenCVConfig.cmake into 2-level mode for Android SDK
Some CMake 3.x (2.8.12.2 is fine) provides broken build configurations
with following build error message:
ld: fatal error: -soname: must take a non-empty argument
Linker command line sample contains this:
"-shared -Wl,-soname, -o"
* check compiler support
* check HW support before executing
* add test doing round trip conversion from / to FP32
* treat array correctly if size is not multiple of 4
* add declaration to prevent warning
* make it possible to enable fp16 on 32bit ARM
* let the conversion possible on non-supported HW, too.
* add test using both HW and SW implementation
Command line generation routine uses "-isystem" to include headers outside of "<opencv>/modules" folder, but GCC 6 does not work when passed "-isystem /usr/include" option.
Commits:
67fe57a add fixed video
db0ae2c Restore 2.4 source branch for bug fix 6317.
97ac59c Fix a memory leak indirectly caused by cvDestroyWindow
eb40afa Add a workaround for FFmpeg's color conversion accessing past the end of the buffer
421fcf9 Rearrange CvVideoWriter_FFMPEG::writeFrame for better readability
912592d Remove "INSTALL_NAME_DIR lib" target property
bb1c2d7 fix bug on border at pyrUp
syntax of cmake "get_filename_component" changed after version 2.8.11
for cmake version < 2.8.11
get_filename_component(<VAR> <FileName> PATH [CACHE])
for cmake version >= 2.8.11
get_filename_component(<VAR> <FileName> DIRECTORY [CACHE])
Update OpenCVConfig.cmake
Update OpenCVConfig.cmake.in
The INSTALL_NAME_DIR property of a target specifies how a dynamic library should
be found on OS X. If INSTALL_NAME_DIR is not specified the loader will search
relative to the standard search paths. If specified it should either be
an absolute path or relative path prefixed with either @executable_path,
@load_path, or @rpath. Specifying "lib" does not make sense here and
causes linking error as documented here:
http://answers.opencv.org/question/4134/cmake-install_name_tool-absolute-path-for-library-on-mac-osx/
and here
http://stackoverflow.com/questions/26978806/dyld-library-not-loaded-lib-libopencv-core-3-0-dylib-reason-image-not-found
This patch removes INSTALL_NAME_DIR everywhere it is set to "lib".
An alternate solution would be to set an absolute path like
"${CMAKE_INSTALL_PREFIX}/lib" or relative path like
"@executable_path/../lib". However, if there is not specific need for
specifying a path, it is probably best left unset.
If I ask for version 2, the current trunk version (version 3), will say it is compatible, which is erroneous.
Do not consider different major versions compatible in cmake config file
PR #2968: cce2d998578f9c
Fixed bug which caused crash of GPU version of feature matcher in stitcher
The bug caused crash of GPU version of feature matcher in stitcher when
we use ORB features.
PR #3236: 5947519
Check sure that we're not already below required leaf false alarm rate before continuing to get negative samples.
PR #3190
fix blobdetector
PR #3562 (part): 82bd82e
TBB updated to 4.3u2. Fix for aarch64 support.
PR #3604 (part): 091c7a3
OpenGL interop sample reworked not ot use cvconfig.h
PR #3792: afdf319
Add -L for CUDA libs path to pkg-config
Add all dirs from CUDA_LIBS_PATH as -L linker options to
OPENCV_LINKER_LIBS. These will end up in opencv.pc.
PR #3893: 122b9f8
Turn ocv_convert_to_lib_name into a function
PR #5490: ec5244a
fixed memory leak in findHomography tests
PR #5491: 0d5b739
delete video readers
PR #5574
PR #5202
- added new functions from core module: split, merge, add, sub, mul, div, ...
- added function replacement mechanism
- added example of HAL replacement library
Pdb file support was changed in CMake 2.8.12, support was added in CMake 3.1.0 to work around the problems created by the change introduced in CMake 2.8.12.
Command 'execute_process' from OpenCVFindMatlab module can omit error message
to the standard output. This can break build of the OpenCV package in
ExternalProject_Add (Windows/Visual Studio).
Scripts are updated for Linux-based (Ubuntu 14.04) mingw cross-compilation (full stack of scripts provided)
Part of these scripts may work under Windows installation of MinGW, but it is not supported.
FFMPEG update: 2.7.1
Added OpenH264 Cisco binaries support for H264 encoding: v1.4.0
With this fix there is no need to add includes by using
`include_directories(${OpenCV_INCLUDE_DIRS})`. Directory will be added by
command `target_link_libraries(... ${OpenCV_LIBS})` automatically.
Using absolute path to locate the components in the "Libs:" field of the
*.pc can badly break cross-compilation, especially when building
statically linked objects.
Indeed, pkg-config automatically replaces the '-I...' and '-L...' paths
when the PKG_CONFIG_SYSROOT_DIR and PKG_CONFIG_LIBDIR environment
variables are set [1]. This feature is very helpful and common in
cross-compilation framework like Buildroot [2,3].
When there are absolute paths in the *.pc files, pkg-config won't be
able to do the path substitutions for these paths when the
aforementioned environment variables are set.
In such case, since the prefix is the target one, not the sysroot one,
these libraries' absolute paths will point to:
- in the best case: a non-existing file (i.e. these files do not exists
on the host system;
- at worst: the host system's libraries. This will make the linking
failed because these host system's libraries will most likely not be
build for the target architecture [4].
So, this patch replace the components' absolute paths by the form:
-L<libdir> -l<libname>
This way, the linker will be able to resolve each dependency path,
whatever the kind of objects/build (shared object or static build) it
is dealing with.
Note that for static link, the library order does matter [5]. The order
of the opencv components has been carefully chosen to comply with this
requirement.
Fixes#3931
This patch is a port of [6] on the master branch.
[1] http://linux.die.net/man/1/pkg-config
[2] http://buildroot.org/
[3] http://git.buildroot.net/buildroot/tree/package/pkgconf/pkg-config.in
[4] http://autobuild.buildroot.net/results/e8a/e8a859276db34aff87ef181b0cce98916b0afc90/build-end.log
[5] http://stackoverflow.com/questions/45135/linker-order-gcc
[6] eceada586b
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
Without the fix, OpenCV will compile and silently copy the compiled libs/executables to a location not prefixed with arch/vc14, and OpenCV won't be picked up by find_package and OpenCVConfig.cmake.
Also:
- Silence clang warnings about unsupported command line arguments
- Add diagnostic print to calib3d test
- Fixed perf test relative error check
- Fix iOS build problem
The use of built-in CMAKE_CURRENT_LIST_DIR requires at least
CMake 2.8.3. This fix properly defines the variable to allow its
use in versions < 2.8.3 as well.
Fixes issue #4205.
Exclude >= 2.8.3 from reimplementation of CMAKE_CURRENT_LIST_DIR
This avoids violation of possible future CMake policy checks
regarding reserved/read-only variables.
find_package(PythonInterp) calls find_program(PYTHON_EXECUTABLE), i.e. without version number. For the Win32-search before to be effective, the same variable has to be used.
This retains the desirable quality of not including paths to CUDA libraries
from the build system into the config files, and has two major advantages:
* It removes the need to use link_directories, which doesn't guarantee that
the libraries from the supplied directory will be used (there may be
libraries with the same names earlier in the search path).
* It removes the need to put -L entries into OPENCV_LINKER_LIBS. This variable
is used with target_link_libraries, where such entries are treated as linker
flags, so doing this is unportable. I remove the support for -L entries
from OpenCVGenPkgconfig.cmake, as well, to discourage adding them in the
future.
Make detection of x64 using the gcc's target triplet identical
to the one used in cmake/OpenCVDetectCXXCompiler.cmake.
Otherwise, MinGW-w64 setups will always be treated as x64 since
they contain "w64" as vendor key.
MinGW-w64 always uses "w64" as vendor key which the previously
used check for "64" anywhere in the target triplet matched. This
would lead to MinGW-w64 setups always being treated as x64.
Turns out we do not even need this additional check since the
architecture has been correctly determined earlier in this file.
No need to do it again.
HAVE_VFW flag is defined by CMake try_compile check.
Check fails for WINRT as vfw.h begins with
and contains empty set of functions for Store apps.
So we can safely remove vfw32.lib for WINRT in general
(independently of availability for specific configuration)
Which also happens to align the non-Debian specific variables
with the ones used by upstream CMake.
(cherry picked from commit b8c60234c3)
Conflicts:
cmake/OpenCVPackaging.cmake
It's pretty much a simplified copy of the Linux script, lacking fancy colors.
Also, I had to drop Python testing, because it's not easy to pass the Python
module location to the script, and I have no pressing need to run the Python
tests at the moment.
(cherry picked from commit c1e3ca170e)
Conflicts:
CMakeLists.txt
They don't actually do anything. And even if they did, all components are
enabled by default, anyway.
(cherry picked from commit 49fe496914)
Conflicts:
cmake/OpenCVPackaging.cmake
Make detection of x64 using the gcc's target triplet identical
to the one used in cmake/OpenCVDetectCXXCompiler.cmake.
Otherwise, MinGW-w64 setups will always be treated as x64 since
they contain "w64" as vendor key.
