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