OIIO 1.8.6 fails to build from source (FTBFS) on arm{el,hf} in Debian

[mfvescovi]

Hi Larry!

While building brand new 1.8.6 on Debian buildd infrastructure, armel and armhf builds fail due to some Qt5 conflicting declaration.

A snip of the first error in buildlog reports:

[ 91%] Building CXX object src/iv/CMakeFiles/iv.dir/imageviewer.cpp.o
cd "/<>/build/src/iv" && /usr/bin/c++ -DQT_CORE_LIB -DQT_GUI_LIB -DQT_NO_DEBUG -DQT_OPENGL_LIB -DQT_WIDGETS_LIB -DUSE_FREETYPE -DUSE_OCIO=1 -DUSE_OPENCV -DUSE_STD_REGEX -D__STDC_CONSTANT_MACROS -D__STDC_LIMIT_MACROS -I"/<>/build/src/iv/iv_autogen/include" -I"/<>/build/include" -I"/<>/src/include" -I/usr/include/arm-linux-gnueabi -I/usr/include/OpenEXR -I/usr/include/GL -isystem /usr/include/arm-linux-gnueabi/qt5 -isystem /usr/include/arm-linux-gnueabi/qt5/QtCore -isystem /usr/lib/arm-linux-gnueabi/qt5/mkspecs/linux-g++ -isystem /usr/include/arm-linux-gnueabi/qt5/QtGui -isystem /usr/include/arm-linux-gnueabi/qt5/QtWidgets -isystem /usr/include/arm-linux-gnueabi/qt5/QtOpenGL -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIE -Wall -fno-math-errno -Wno-error=unused-local-typedefs -Wno-unused-local-typedefs -Wno-unused-result -Wno-error=misleading-indentation -Wno-aligned-new -Wno-error=noexcept-type -std=c++11 -UUSE_FIELD3D -fPIC -std=gnu++11 -o CMakeFiles/iv.dir/imageviewer.cpp.o -c "/<>/src/iv/imageviewer.cpp"
In file included from /usr/include/arm-linux-gnueabi/qt5/QtGui/qopengl.h:107:0,
from /usr/include/arm-linux-gnueabi/qt5/QtOpenGL/qgl.h:45,
from /usr/include/arm-linux-gnueabi/qt5/QtOpenGL/QGLWidget:1,
from /<>/src/iv/imageviewer.h:50,
from /<>/src/iv/imageviewer.cpp:38:
/usr/include/GLES3/gl3.h:75:25: error: conflicting declaration 'typedef khronos_ssize_t GLsizeiptr'
typedef khronos_ssize_t GLsizeiptr;
^~~~~~~~~~

Both armel and armhf are facing the same errors.
I'm attaching both buildlogs for your convenience.

Thanks in advance.

oiio_1.8.6_on_armel.buildlog
oiio_1.8.6_on_armhf.buildlog

[mfvescovi]

FTR, Debian bug report #881679 has been opened for this issue.

[lgritz]

Is this the first time you've built a 1.8.x, or has something changed recently?

Do you actually build and use iv intentionally? Is disabling it an option that would have any negative consequences for you on those platforms?

[lgritz]

"khronos_ssize_t" does not appear anywhere in our source code, so it must be that it's redundantly defined in system headers that we include (probably something from qt and from gl3.h itself?). Hard to know how to address that exactly since it's not in our code.

To be honest, I've been meaning to explore whether there's any point in using OpenGL in iv -- it could be done just with straight-up Qt QPixmap widget, I guess. (Qt uses OpenGL underneath, when it helps, so I'm not sure there's a significant performance reason to use it ourself in this case, since we're not really doing any 3D, or anything challenging at all in 2D.)

But I don't know how big a job that is. If you don't really need iv for this platform, I think the expedient thing is to just build with USE_OPENGL=0 to disable it for now. When I get around to that experiment of "iv without OpenGL" (which should be soon, I need to do something similar later this week for another project), then maybe we can re-enable it for all platforms?

[mfvescovi]

Hi Larry!

Is this the first time you've built a 1.8.x, or has something changed recently?

Well, no. I tested OIIO 1.8.6 on the experimental suite in Debian to check if reverse dependencies were actually building fine with it. And they did (with a little patch applied for Blender).
Then I uploaded it to unstable/sid and let it build elsewhere (to have a common version on all release architectures) and finally moved to use Qt5 libraries instead of Qt4 (deprecated almost).
These are the results for latest builds on armel (armhf is almost identical).

Do you actually build and use iv intentionally? Is disabling it an option that would have any negative consequences for you on those platforms?

Probably no. Most users are amd64/i386 based. I could try ti disable iv compilation for arm{el,hf} (while leaving it for arm64) and see if someone complains ;-)

[mfvescovi]

But I don't know how big a job that is. If you don't really need iv for this platform, I think the expedient thing is to just build with USE_OPENGL=0 to disable it for now. When I get around to that experiment of "iv without OpenGL" (which should be soon, I need to do something similar later this week for another project), then maybe we can re-enable it for all platforms?

Sure. Let's try. I'll keep you updated how it goes.

[mfvescovi]

OK, so disabling OpenGL helped, as you can see on buildd.

When I get around to that experiment of "iv without OpenGL" (which should be soon, I need to do something similar later this week for another project), then maybe we can re-enable it for all platforms?

Let's hope to be able to re-add this feature again soon.

[mfvescovi]

Last night the bug report #881943 was filed against Qt5 library and it seems extremely related to the issue I faced. So probably, once this lack got fixed on the Debian package, I'll be able to re-add OpenGL support.

[mfvescovi]

Hi again, @lgritz!

When I get around to that experiment of "iv without OpenGL" (which should be soon, I need to do something similar later this week for another project), [...]

Had you got the chance to check this? Today I got #883552 on Debian BTS about the missing "iv" tool, that was dropped when I disabled OpenGL support.

I really hope you have some good news for me ;-)

[lgritz]

The good news is that I finished that other app, in which I needed to display images rapidly and did it with straight Qt pixmaps, no OpenGL (though underneath, I think Qt knows to use GL when and where appropriate). And it worked great. So I think there are no technical reasons we shouldn't do this for iv as well, and I know how to do it.

The bad news is that I haven't yet done any of the work on the iv end, and it probably is quite a bit of work to excise the GL and replace it -- and be sure we haven't lost any features in the process. Also, it's such a big change that I don't want to predict the degree to which I'd be willing to backport it to a release branch, versus letting it stew in master for quite a while to be certain that it's the path forward.