int pix_per_thr = l_counter / LOCAL_TOTAL + ((lid < mod) ? 1 : 0);
The pix_per_thr * LOCAL_TOTAL may be larger than l_counter.
Thus the index of l_stack may be negative which may cause serious
problems. Let's skip the loop when we get negative index and we need
to add back the lcounter to keep its balance and avoid potential
negative counter.
Signed-off-by: Zhigang Gong <zhigang.gong@intel.com>
Some TIFF images consist of only one strip. The magic value 2**32-1 for the
"rows per strip" tag reflects that fact, effectively meaning "infinite".
Conflicts:
modules/highgui/src/grfmt_tiff.cpp
modules/highgui/test/test_grfmt.cpp
fix whitespace
fix compile error
Fixed a memory leak in cap_dshow.cpp in videoInput::setVideoSettingCamera(). The leak was caused by not releasing an IBaseFilter object created in a call to getDevice(). Tho object is now properly released.
Conflicts:
modules/highgui/src/cap_dshow.cpp
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>
