OpenCV 4.0.0 has been released

[zdenop]

OpenCV 4.0.0 was releases 14 day ago: https://github.com/opencv/opencv/releases/tag/4.0.0
It there plan to release opencv-python 4.0.0?

[zdenop]

related to #137

[skvark]

Yes. I'll have to check first that it builds fine. However, the builds take tens of hours of time so I can't just release them without being able to monitor the build process closely. I might be able to do the release during this week.

[albertofernandezvillan]

Any updates?

[skvark]

Linux builds are failing (and macOS too, but that might be fixed when the builds are rebuilt a few times). I have to check what's going on on Linux.

[zdenop]

https://www.learnopencv.com/install-opencv-4-on-centos-7/ does not help?

[skvark]

Unfortunately basic compilation guides don't help in this case. The error is related to custom CentOS 5 i686 images and to some type error. However, macOS images and 64-bit Linux builds are fine.

[LaurentBerger]

How can we help you ? Can you post full error message ?

[skvark]

You can see the full error messages if you have a look the failed builds for example here: https://travis-ci.org/skvark/opencv-python/builds/470937189

First one:

In file included from /io/opencv/modules/videoio/src/cap_v4l.cpp:232:0:
/usr/include/linux/videodev2.h:1112:9: error: ‘__u64’ does not name a type
 typedef __u64 v4l2_std_id;

For some reason (maybe because of an ancient kernel) the type __u64 is not recognized. I just bumped the OpenCV version to 4.0.1 to see if the error is`caused just by some bug in 4.0.0 or is it related to the build environment.

[skvark]

Found the issue after reading some Linux kernel code. To reproduce:

#include <iostream>
#include <asm/types.h>          /* for videodev2.h */
#include <linux/videodev2.h>
using namespace std;

int main()
{
    cout << "Hello, World!";
    return 0;
}

c++ test.cpp -o test -std=c++11 yields:

In file included from test.cpp:3:0:
/usr/include/linux/videodev2.h:1112:9: error: ‘__u64’ does not name a type
 typedef __u64 v4l2_std_id;
         ^
/usr/include/linux/videodev2.h:1242:2: error: ‘v4l2_std_id’ does not name a type
  v4l2_std_id          id;
  ^
/usr/include/linux/videodev2.h:1293:2: error: ‘__u64’ does not name a type
  __u64 pixelclock;
  ^
/usr/include/linux/videodev2.h:1446:2: error: ‘__u64’ does not name a type
  __u64 min_pixelclock;
  ^
/usr/include/linux/videodev2.h:1447:2: error: ‘__u64’ does not name a type
  __u64 max_pixelclock;
  ^
/usr/include/linux/videodev2.h:1488:2: error: ‘v4l2_std_id’ does not name a type
  v4l2_std_id  std;
  ^
/usr/include/linux/videodev2.h:1540:2: error: ‘v4l2_std_id’ does not name a type
  v4l2_std_id  std;
  ^
/usr/include/linux/videodev2.h:1569:3: error: ‘__s64’ does not name a type
   __s64 value64;
   ^
/usr/include/linux/videodev2.h:1637:2: error: ‘__s64’ does not name a type
  __s64       minimum;
  ^
/usr/include/linux/videodev2.h:1638:2: error: ‘__s64’ does not name a type
  __s64       maximum;
  ^
/usr/include/linux/videodev2.h:1639:2: error: ‘__u64’ does not name a type
  __u64       step;
  ^
/usr/include/linux/videodev2.h:1640:2: error: ‘__s64’ does not name a type
  __s64       default_value;
  ^
/usr/include/linux/videodev2.h:1655:3: error: ‘__s64’ does not name a type
   __s64 value;
   ^
/usr/include/linux/videodev2.h:1833:2: error: ‘__u64’ does not name a type
  __u64 offset;
  ^
/usr/include/linux/videodev2.h:1834:2: error: ‘__u64’ does not name a type
  __u64 pts;
  ^
/usr/include/linux/videodev2.h:1897:4: error: ‘__u64’ does not name a type
    __u64 pts;
    ^
/usr/include/linux/videodev2.h:2178:3: error: ‘__s64’ does not name a type
   __s64 value64;
   ^
/usr/include/linux/videodev2.h:2268:2: error: ‘__u64’ does not name a type
  __u64 reg;
  ^
/usr/include/linux/videodev2.h:2269:2: error: ‘__u64’ does not name a type
  __u64 val;

The type definitions are protected in asm/types.h by __STRICT_ANSI__ macro.
If I run c++ test.cpp -o test -std=c++11 -U__STRICT_ANSI__ the test file compiles just fine.

I'm not sure if it is a good idea to disable that macro, but let's see how the build goes...

[skvark]

Builds are passing now. I will create a release tomorrow after the current CI jobs are done.

[skvark]

The builds are now in progress. Please note that it takes about 16 hours before all the packages are available to install from PyPI.