Error when try to compile on Mac OS X with GNU GCC 5.3

[lneequals1]

Try to compile on Mac OS X 10.11 with GNU GCC 5.3, everything is fine with cmake.

But when I start to make, the following error occurs.

[plstcharles]

Hello!

Interesting problem: are you sure you tried to compile with GCC 5.3, and not an older GCC binary? Since 4.8, the '-Wmissing-braces' option should no longer be triggering warnings when using arrays-in-arrays without double braces --- see here.

If you are in fact using GCC 5.3, it might be caused by some platform-specific issue in GCC --- just confirm it here, and I will patch the top-level CMakeLists.txt for OSX to remove/ignore the '-Wmissing-braces' flag (it is included by default with '-Wall').

-PLSTC

[lneequals1]

Yeah.., I think that I'm using GCC 5.3.

Here is the link to this version of GCC, not sure if it is a motified version. http://hpc.sourceforge.net

[plstcharles]

Alright, fix is going in then! I patched the top-level CMakeLists.txt in the master branch to disable the culprit flag --- let me know if you have any other issues while compiling (I believe you're the first in quite a few months to compile the framework on OS X).

[lneequals1]

Hi.. it seems there is another error -Wshadow in the same file opencv.cpp.

I suppose this version of GCC simply doesn't work.

[plstcharles]

Well this is very interesting indeed; it seems that the options your GCC was built with make it way more sensitive than the ones I use (4.8.2 and 5.4.0 on Ubuntu). The 'shadowed variable' warning is never triggered on my side, not even on MSVC2015 in super-verbose-mode. In this particular case, the local structure (the object wrapper) cannot use variables from the parent scope, but GCC thinks it can, and acts as if there might be ambiguity between names.

I will patch all the culprit code segments in a few moments --- let's hope that solves it! Besides, to make sure you don't waste too much time on warning-as-errors issues, I will disable this option in CMake for OS X builds. If you do complete a build after that, could you post your compilation output here? I'll try to fix all warnings that pop up.

Thanks for the feedback!

[lneequals1]

Hi, I think I forgot to tell you that I've manuelly modified the CMakeList.txt to make it run. I changed the following lines from "Clang" to "AppleClang"

Otherwise with "Clang" I get.

So I think somehow I'm still using "AppleClang" (or the GNU I'm using is just a wrapper of AppleClang) and with "AppleClang" the compile error changes to:

I modified this line and add tmplate in front of shared_from_this_cast

then the error becomes

it seems AppleClang doesn't know this function.

[plstcharles]

Hello again!

I downloaded Clang 3.8 and fixed all the issues I could find on my side. For the missing 'aligned_alloc' function, I wrote a workaround using posix_memalign, which should be available on OS X (although I cannot test it). I also rewrote part of the top-level CMakeLists.txt to properly detect and group 'AppleClang' with regular 'Clang', so both can share compiler options.

Let me know if you run into any more issues!

[ln1equals0]

Hi, I think I've already fix all the issues for now, some of those are only work around, here is how.

I switched back to the original "AppleClang" (and GNU GCC still has compile errors on my end) (For those who don't know, I use macOS 10.11 El Capitan)

Fresh download the codebase

1). mkdir build, cd build, cmake ..

CMake Error:

I used this one: https://github.com/jevinskie/cmake/blob/master/Modules/CheckFunctionExists.cmake

and add a line in cmakelist.txt

2) make

I just want to test what other error there is, so I commented the following lines

at least posix_memalign works on mac

3) make again

it seems the compiler doesn't know the type of nThreshold, so I make the following changes

4) make again

so I added the header file,

5) finally the make passed

and I tested some samples and it works

the remaining issue: GNU GCC both 5.3 and 6.2 doesn't work for me, it has compile error e.g. undefined symbol of cv:: and lv:: and 1) is really just work around, have no idea why HAVE_STL_ALIGNED_ALLOC is not set

Best

[plstcharles]

Great, thanks for the feedback!

I will try to patch the framework this afternoon with workarounds for your issues, at least people coming in with similar platform/toolsets might be able to avoid these in the future.