Ask Your Question
0

Failure to build Python bindings under mingw32

asked 2016-01-19 10:23:29 -0600

aag gravatar image

OpenCV 3.0 fails to build with the following error:

   [100%] Generating pyopencv_generated_include.h, pyopencv_generated_funcs.h, pyopencv_generated_types.h, pyopencv_generated_type_reg.h, pyopencv_generated_ns_reg.h
    cd /c/prj/videoLib/.build/MINGW32_NT-10.0-WOW/i386/opencv/modules/python2 && /c/Python27/python.exe /c/prj/videoLib/.build/MINGW32_NT-10.0-WOW/i386/opencv/modules/python/python2/..//src2/gen2.py /c/prj/videoLib/.build/MINGW32_NT-10.0-WOW/i386/opencv/modules/python2 /c/prj/videoLib/.build/MINGW32_NT-10.0-WOW/i386/opencv/modules/python2/headers.txt
    Traceback (most recent call last):
      File "C:/prj/videoLib/.build/MINGW32_NT-10.0-WOW/i386/opencv/modules/python/python2/..//src2/gen2.py", line 940, in <module>
        generator.gen(srcfiles, dstdir)
      File "C:/prj/videoLib/.build/MINGW32_NT-10.0-WOW/i386/opencv/modules/python/python2/..//src2/gen2.py", line 865, in gen
        decls = self.parser.parse(hdr)
      File "C:\prj\videoLib\.build\MINGW32_NT-10.0-WOW\i386\opencv\modules\python\src2\hdr_parser.py", line 746, in parse
        f = io.open(hname, 'rt', encoding='utf-8')
    IOError: [Errno 2] No such file or directory: '/c/prj/videoLib/.build/MINGW32_NT-10.0-WOW/i386/opencv/modules/core/include/opencv2/core.hpp'
    modules/python2/CMakeFiles/opencv_python2.dir/build.make:146: recipe for target 'modules/python2/pyopencv_generated_include.h' failed

The file in question (core.hpp) is present in the location being looked at, but I'd guess the problem is that the paths are provided to Python in mingw, rather than standard Windows form.

Is there a way to build OpenCV under mingw? Seems to work just fine, as long as Python bindings aren't required -- but when those are needed things go downhill fast.

The final config status reported by cmake looks like this

-- General configuration for OpenCV 3.0.0 =====================================
--   Version control:               3.0.0-dirty
--
--   Platform:
--     Host:                        MINGW32_NT-10.0-WOW 2.4.0(0.292/5/3) unknown
--     CMake:                       3.2.3
--     CMake generator:             Unix Makefiles
--     CMake build tool:            /usr/bin/make.exe
--     Configuration:               Release
--
--   C/C++:
--     Built as dynamic libs?:      YES
--     C++ Compiler:                /mingw32/bin/c++.exe  (ver 5.2.0)
--     C++ flags (Release):         -m32    -fsigned-char -mstackrealign -W -Wall -Werror=return-type -Werror=non-virtual-dtor -Werror=address -Werror=sequence-point -Wformat -Werror=format-security -Wmissing-declarations -Wundef -Winit-self -Wpointer-arith -Wshadow -Wsign-promo -Wno-narrowing -Wno-delete-non-virtual-dtor -fdiagnostics-show-option -march=i686 -fomit-frame-pointer -msse -msse2 -mfpmath=sse -ffunction-sections -fvisibility=hidden -fvisibility-inlines-hidden -O2 -DNDEBUG  -DNDEBUG
--     C++ flags (Debug):           -m32    -fsigned-char -mstackrealign -W -Wall -Werror=return-type -Werror=non-virtual-dtor -Werror=address -Werror=sequence-point -Wformat -Werror=format-security -Wmissing-declarations -Wundef -Winit-self -Wpointer-arith -Wshadow -Wsign-promo -Wno-narrowing -Wno-delete-non-virtual-dtor -fdiagnostics-show-option -march=i686 -fomit-frame-pointer -msse -msse2 -mfpmath=sse -ffunction-sections -fvisibility=hidden -fvisibility-inlines-hidden -g  -O0 -DDEBUG -D_DEBUG
--     C Compiler:                  /mingw32/bin/gcc.exe
--     C flags (Release):           -m32    -fsigned-char -mstackrealign -W -Wall -Werror=return-type -Werror=non-virtual-dtor -Werror=address -Werror=sequence-point -Wformat -Werror=format-security -Wmissing-declarations -Wmissing-prototypes -Wstrict-prototypes -Wundef -Winit-self -Wpointer-arith -Wshadow -Wno-narrowing -fdiagnostics-show-option -march=i686 -fomit-frame-pointer -msse -msse2 -mfpmath=sse -ffunction-sections -fvisibility=hidden -O2 -DNDEBUG  -DNDEBUG
--     C flags (Debug):             -m32    -fsigned-char -mstackrealign -W -Wall -Werror=return-type -Werror=non-virtual-dtor -Werror=address -Werror=sequence-point -Wformat -Werror=format-security -Wmissing-declarations -Wmissing-prototypes -Wstrict-prototypes -Wundef -Winit-self -Wpointer-arith -Wshadow -Wno-narrowing -fdiagnostics-show-option -march=i686 -fomit-frame-pointer -msse -msse2 -mfpmath=sse -ffunction-sections -fvisibility=hidden -g  -O0 -DDEBUG -D_DEBUG
--     Linker flags (Release):      -static-libgcc ...
(more)
edit retag flag offensive close merge delete

Comments

are you using some weird kind of cygwin shell there ?

No such file or directory: '/c/prj/videoLib/.build/MINGW32_NT-10.0-WOW/i386/opencv/modules/core/include/opencv2/core.hpp'

try to run on a plain cmd.exe instead,

i'm pretty sure, that python will find c:/prj/videoLib/.build/MINGW32_NT-10.0-WOW/i386/opencv/modules/core/include/opencv2/core.hpp , but not , what you supply there.

berak gravatar imageberak ( 2016-01-19 10:32:35 -0600 )edit

Yes, msys shell is being used. That (or cygwin) is the common way of using mingw on Windows, isn't it?

The problem wouldn't have occurred, if the list of files was passed inline (msys/mingw converts the paths), rather than via file. Or if relative paths were used. Can either of these options be entertained?

aag gravatar imageaag ( 2016-01-19 10:54:13 -0600 )edit

again , try without msys

berak gravatar imageberak ( 2016-01-19 10:56:32 -0600 )edit

no, it's not the common way, it's just one of many. since it seems to get in your way, get rid of it.

berak gravatar imageberak ( 2016-01-19 10:57:11 -0600 )edit

So, if not msys, what would be your shell of choice on Windows, then?

aag gravatar imageaag ( 2016-01-19 11:02:19 -0600 )edit

again, fire up a plain cmd.exe, and try again (running cmake)

berak gravatar imageberak ( 2016-01-19 11:05:16 -0600 )edit

1 answer

Sort by ยป oldest newest most voted
0

answered 2016-01-21 16:28:03 -0600

aag gravatar image

While cmd.exe may work, the need to use Windows scripting may prove a dealbreaker for some, from both portability and sanity perspective.

Luckily, there's an alternative solution I've found: 1) Do not use cmake on mingw/msys. Instead, rely on cmake version installed on Windows host. 2) Use -G "MSYS Makefiles" when invoking cmake

In this configuration things seem to work much better.

edit flag offensive delete link more

Question Tools

1 follower

Stats

Asked: 2016-01-19 10:23:29 -0600

Seen: 802 times

Last updated: Jan 21 '16