| Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
|---|---|---|---|---|---|---|
| 0001-Fix_built-in_documentation_dependencies.patch | Fix_built-in_documentation_dependencies | "Matteo F. Vescovi" <mfv@debian.org> | no | 2018-01-18 | ||
| 0002-Fix_FTBFS_on_non-Linux_platforms.patch | Fix_FTBFS_on_non-Linux_platforms | "Matteo F. Vescovi" <mfv@debian.org> | no | 2018-01-18 | ||
| 0003-Fix_Linux_compilation.patch | Fix_Linux_compilation | Patrick Hodoul <patrick.hodoul@autodesk.com> | no | 2019-04-09 | ||
| 0004-Fix_build_with_GCC-8.patch | Fix_build_with_GCC-8 GCC 8 appears to be rather stricter about various issues to do with type conversions and casts than GCC 7 was. This affects OpenColorIO's Python bindings quite heavily, producing a large number of warnings (which are converted to errors by `-Werror`) and outright errors. The changes here are almost all one of three basic types: 1. Many functions that become Python methods with no arguments (using the METH_NOARGS flag) did not include the expected second parameter in their signatures at all. METH_NOARGS does not prevent this second parameter being passed *at all*, it only ensures that it will always be NULL. It's still not technically correct to leave it out of the function signature; as a comment from 'yak' on https://stackoverflow.com/questions/10256315 points out, there are situations where this could cause a crash. I've added the second parameter (with no name, per convention) to every one of these cases. 2. In several cases, classes specified a custom destructor, with a cast to the `destructor` type, which only takes a single parameter. However, the signatures for these destructor functions included two parameters, assuming that they'd get an 'args' parameter (they do not). I've corrected all these cases. 3. In several cases, classes specified custom str or repr methods. However, in the `PyTypeObject` structures for these classes, these methods were not cast to the `reprfunc` type, as they ought to be. I've added these casts. There are two warnings I just can't get rid of with my limited C++ knowledge. The `Config` class (in PyConfig.cpp) defines a couple of methods that take kwargs as well as args. This is done by setting the `METH_KEYWORDS` flag, which ultimately seems to result in a cast from type `PyCFunctionWithKeywords` to `PyCFunction` happening somewhere behind the scenes. There's some discussion of this at https://stackoverflow.com/questions/9496753 GCC 8 does not like this cast - it causes a 'cast-function-type' warning. I've messed around a bit with `reinterpret_cast` and stuff, but didn't really understand precisely what I was doing and didn't manage to find anything that got rid of the warnings. So I just suppressed these warnings with GCC pragmas instead (using `-Wno-error=cast-function-type` causes older GCC versions to choke, so we can't do that). I've tested at least that the compilation succeeds, and I can import the Python module and instantiate a few classes and examine their docstrings and stuff with no apparent errors. Many thanks to Kevin Kofler for his help with these fixes. |
Adam Williamson <adamw@happyassassin.net> | no | 2018-03-21 | ||
| 0005-Fix_build_with_yaml-cpp0.6.patch | Fix_build_with_yaml-cpp0.6 One of the changes in yaml-cpp 0.6 was the replacement of some inline virtual functions with out-of-line virtual functions, to ensure a single definition of the relevant vtable. Unfortunately, OpenColorIO forward-declares these classes with a different GCC visibility attribute. Now that the key function for the vtables is not inlined into code using yaml-cpp.h that breaks link-time resolution of the vtables. |
Christopher James Halse Rogers <christopher.halse.rogers@canonical.com> | yes | upstream | 2019-04-09 |