This post started out as a question, but morphed into a notification of multiple problems I had building opencv 3 with IPP "out of the box", and to provide a workaround, which works for me at least.

Here's a summary of my issues:

1. Opencv3 does not build out of the box with the supplied IPP libraries. This is an apparent link failure, and happens with several objects.
2. Opencv3 does not recognize the IPPROOT environment variable, which I believe is a standard environment variable used when IPP is already installed on a system
3. I could find no documentation on how to direct OpenCV to look for the existing IPP on the system, and had to search thru included cmake files to find the right flag.
4. OpenCV3 does not work with IPP 9, due to Intel removing the libippm.a library, and OpenCV still looking for it.
5. sudo make install doesnt work, as the linker cannot find several of the IPP libraries (libirc, libimf, libsvml)

Solution (at least for me):

1. edit cmake/OpenCVFindIPP.cmake, and comment out the line _ipp_add_library(m)
2. build with D IPPROOT='pathToMyIPP'
3. instead of sudo make install, need to ensure that the root user has sourced the appropriate Intel compilervars script (for me its /opt/intel/bin/compilervars.sh intel64), then do
   su make install

Details:

I've been using opencv 2.4.x for awhile now but need to upgrade to 3 to get functionality that doesnt exist in 2.4.x. I downloaded 3.1.0 from the website and tried to build i (only flag I used was -D CMAKE_BUILD_TYPE=RELEASE) . It fails when trying to link with the IPP that comes bundled in the 3rdparty directory of opencv 3. I have a CentOS version of linux, but I'm fairly certain that CentOS does not play in any of these problems.

Problems using OpenCV-provided IPP:

On compile (make stage), there's a ton of errors that look like:
../../lib/libopencv_imgproc.so.3.1.0: undefined reference to ippiCopySubpixIntersect_8u_C1R' ../../lib/libopencv_imgproc.so.3.1.0: undefined reference toippiCopy_32f_AC4C3R' ../../lib/libopencv_imgproc.so.3.1.0: undefined reference to ippiDistanceTransform_5x5_8u32f_C1R' ../../lib/libopencv_imgproc.so.3.1.0: undefined reference toippiFilterBorder_32f_C1R' ../../lib/libopencv_imgproc.so.3.1.0: undefined reference to ippiFilterBorderInit_32f' ../../lib/libopencv_imgproc.so.3.1.0: undefined reference toippiResizeCubic_32f_C3R' ../../lib/libopencv_core.so.3.1.0: undefined reference to `ippiNorm_L2_16u_C1MR'

I see that theres a libippicv.a file included under 3rdparty, and I checked a few of the symbols for existence using nm libippicv.a, and all the symbols I checked exist. I also did a search on the entire opencv3 tree for inclusion of this library in the link line of make files, and it seems to exist. So I'm really confused. Since I have IPP as part of the intel compiler suite I gave up and used the IPP that came from Intel.

Directing CMake to use system IPP

It turns out I have the intel compiler on my system so I tried to use that version of IPP instead. I couldn't find any documentation on how to get that done, I had to search thru various cmake files in order to find that you need to provide the flag -DIPPROOT=<pathtoipp>. This gem was found in cmake/OpenCVFindIPP.cmake, along with a note that says backwards compatibility is broken, and the environment variable IPPROOT is no longer recognized.

Fixing IPP v9.0.1 compatibility problem:

Even after supplying the correct path to IPP, the build failed because OpenCVFindIPP.cmake tries to find/add the library libippm.a to the link line. The offending line in OpenCVFindIPP.cmake is "_ipp_add_library(m). This is the "small matrix" support from intel and was deprecated out of version 9 of the IPP.

Soilving link/install problem (sudo make install)

For me, this was the hardest of the bunch, as I'm not really familiar with the intricacies of CMake. It appears that cmake will strip the full path to a library, if that path exists in the LIBRARY_PATH environment variable (might be other conditions/prerequisites too, like I said I'm Cmake-stupid). This "feature" is in the cmake source code, and exists nowhere in the cmake scripts provided by a user of cmake (ie. you cannot find it thru grep, or trying to unravel cmake scripts and then altering those scripts).

So since I was running the configure and make stages as myself, and I had the path to intel libraries in my LIBRARY_PATH environment variable, the paths to the libraries libirc.so, libimf.so, and libsvml.so were stripped and their place went: -lirc -limf -lsvml.

Now if I try to do: sudo make install, then these libraries are not found for two reasons: a. my root user never ran intel's compilervars.sh script, so when make install is run as root the path to those libraries does not exist in LIBRARY_PATH b. even after fixing that, sudo make install still doesnt work, because it doesnt run (some of????, all of??? ) the bash loginn scripts (is sudo an non-interactive login maybe?)

So I had to both run compilervars.sh script for root logins, and then do: su make install

None if this is standard in my experiences with building/installing codesets.

In Closing.,..

The people involved with OpenCV have created a really awesome framework to learn image/video processing techniques, and then put together solutions to actual problems. I've done a lot of signal processing in my lifetime, and have used many frameworks. From every angle (utility, speed, documentation, provided example code), OpenCV is phenomenal.

It is because it is so awesome that I was willing to spend over a week of very frustrating effort trying to make it work. However I believe you risk turning many away if they have to go thru the same install agonies that I have. Most of my colleagues would have given up on the install and either just gone with OpenCV v2, which to my recollection build and installed normally, OR they would have just rolled their own software.

I realize that as a user I have no right to ask the OpenCV developers to do any additional work. But may I at least suggest that if you have some time that you have put aside to work on OpenCV that you spend a little time trying to address these issues. Specifically:

1. determine/fix why the compile stage fails with the OpenCV provided IPP libraries

2. check for the existence of the IPPROOT environment variable, and then use system-provided IPP before OpenCV's provided IPP. Probably means modifying cmake/OpenCVFindIPP.cmake --- OR --- document the IPPROOT flag on the "cmake" step For me, the first option is preferred, but the second is clearly less work and would suffice.

3. Check the version of IPP being linked with and if it's version 9, dont look for the "m" library (ie. remove the line _ipp_add_library(m) from cmake/OpenCVFindIPP.cmake)

4. If it's possible stop cmake from stripping library paths, OR provide a "-L<pathtolibrary>" directive prior to libraries whose path was stripped OR put a warning in the build documentation that root needs to have the same LIBRARY_PATH, and that you cannot use a non-interactive root login (ie. sudo make install) to complete the install step.