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.
2) disable IPP on 32-bit Linux when OpenCV is built as shared libs. Otherwise we get linker errors
3) disable IPP's minMaxIdx 32-bit floating-point flavor in a hope that it fixes some test failures
- explicitly turning OCL off since WinRT does not support it
- fixing macro definitions in core/ocl.cpp
Signed-off-by: Maxim Kostin <v-maxkos@microsoft.com>
- Substituted HAVE_WINRT with WINRT
- Fixed compilation issues in ocl.cpp and parallel.cpp
- Fixed compiler issue for WP8: "C2678: binary '+' : no operator found which takes a left-hand - Fixed gitignore
- Added #ifdef HAVE_OPENCL to remove compiler warnings in ocl.cpp
- Used NO_GETENV similar to '3rdparty\libjpeg\jmemmgr.c;
- Added ole32.lib for core module (for WindowsStore 8.0 builds)
- Made OpenCV_ARCH aware of ARM
Signed-off-by: Maxim Kostin <v-maxkos@microsoft.com>
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.
Since we are actually interested in finding the "64" in the
triplet's operating system key, this fix makes sure to look for
"mingw64" and thus avoids the false match.
Fixes issue #3835. Credits to Lode Leroy for the original patch.
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.
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.
* improve `CUDA_TARGET_CPU_ARCH` cache initialization,
allow to override initial value from calling script;
* add `CUDA_TARGET_OS_VARIANT` option to select OS variant;
* add `CUDA_TARGET_TRIPLET` option to select target triplet from
`${CUDA_TOOLKIT_ROOT_DIR}/targets` folder;
* remove `CUDA_TOOLKIT_TARGET_DIR` option, now it is calculated from
`CUDA_TARGET_TRIPLET`, the old approach still can be used for compatibility;
* for CUDA 6.5 and newer try to locate static libraries too, because
in 6.5 toolkit for ARM cross compilation only static libraries are included.
This line causes the following error when building custom projects that use OpenCV beta 3:
ld: warning: directory not found for option '-L/<project_root>/-Wl,/usr/local/cuda'
This is actually the same warning that the suppression at the bottom
suppresses, but that one doesn't suppress it when using a native compiler
(go figure).
I remove the forced inclusion of precompiled headers into all sources,
since otherwise this workaround doesn't work - the header with the warning
is included before I can use a pragma.
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 substitions for these paths when the afromentioned
environment variables are set.
In such case, since the prefix is the target one, not the sysroot one,
these libraries' abolute 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
[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
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
---
Note: this patch properly applies on top of the master branch, though it
has been written on top of the 2.4 branch.
"TRUE"/"FALSE" should not be used as literals, as CMake has to decide
whether they are literals or variable names (sigh).
This patch should make it work with any version of CMake and with any
user-side decision on old vs. new policy behavior.
The current situation of the Gstreamer detection does not always honor
all the configurations set by the user, among this:
- if both WITH_GSTREAMER and WITH_GSTREAMER_0_10 are off, but
Gstreamer 0.10 is installed in the system, Gstreamer 0.10 support will
be enable;
- if both WITH_GSTREAMER and WITH_GSTREAMER_0_10 are on, only checks for
Gstreamer 0.10 will be run.
This patch fixes the Gstreamer detection like this:
| -DWITH_... | Package installed || OpenCV |
| GSTREAMER | GSTREAMER_0_10 | gst-1.x | gst-0.10 || gst. support |
+===========+================+=========+==========##==============+
| OFF | OFF | - | - || none |
| OFF | ON | - | no || none |
| OFF | ON | - | yes || gst-0.10 |
| ON | OFF | no | no || none |
| ON | OFF | no | yes || gst-0.10 |
| ON | OFF | yes | - || gst-1.x |
| ON | ON | yes | - || gst-1.x |
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
