* 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>
