[vtkusers] AppImage packaging: GLEW could not be initialized

Mon Jul 11 16:15:37 EDT 2016

2016-07-11 22:14 GMT+02:00 Elvis Stansvik <elvis.stansvik at orexplore.com>:

> 2016-07-11 22:06 GMT+02:00 Ken Martin <ken.martin at kitware.com>:
>
>> glew failing to initialize typically means that opengl has not been
>> initialized, specifically by creating an opengl context. e.g. the
>> this->ContextId is 0. Such as around calls to
>>
>> glXCreateContextAttribsARB
>>
>> in vtkXOpenGLRenderWindow.cxx.
>>
>
> Ah, thanks for the pointers. I'll dig around.
>
>
>>
>>
>> FWIW I do not believe we support the Intel HD3000 on Linux for OpenGL2.
>> You would need either mesa with software rendering, a more recent intel
>> CPU, or a dedicated graphics card and driver.
>>
>
> Hm, but the application runs fine if it's built on the machine itself. I
> only have this problem with the AppImage (so I think it has something to do
> with how I build/package it as such). It's a Thinkpad X220 (Sandybridge)
> with HD 3000 graphics, running 11.2.2 and the
>

*running Mesa 11.2.2.

Elvis

2.99.917+668+gc28e62f version of the intel driver.
>
> When I run it like this (built on the target laptop), the VTK 7.0.0 I use
> is configured with
>
>   for lib in EXPAT FREETYPE JPEG PNG TIFF ZLIB LIBXML2 OGGTHEORA TWISTED
> ZOPE SIX AUTOBAHN MPI4PY JSONCPP GLEW GL2PS; do
>     cmake_system_flags+="-DVTK_USE_SYSTEM_${lib}:BOOL=ON "
>   done
>
> cmake \
>     -Wno-dev \
>     -DCMAKE_SKIP_RPATH=ON \
>     -DBUILD_SHARED_LIBS:BOOL=ON \
>     -DCMAKE_INSTALL_PREFIX:FILEPATH=/usr \
>     -DBUILD_DOCUMENTATION:BOOL=ON \
>     -DDOCUMENTATION_HTML_HELP:BOOL=ON \
>     -DDOCUMENTATION_HTML_TARZ:BOOL=ON \
>     -DBUILD_EXAMPLES:BOOL=ON \
>     -DVTK_USE_FFMPEG_ENCODER:BOOL=ON \
>     -DVTK_BUILD_ALL_MODULES:BOOL=ON \
>     -DVTK_USE_LARGE_DATA:BOOL=ON \
>     -DVTK_QT_VERSION:STRING="5" \
>     -DVTK_WRAP_JAVA:BOOL=ON \
>     -DVTK_WRAP_PYTHON:BOOL=ON \
>     -DVTK_WRAP_TCL:BOOL=ON \
>     -DCMAKE_CXX_FLAGS="-D__STDC_CONSTANT_MACROS" \
>     -DVTK_CUSTOM_LIBRARY_SUFFIX="" \
>     -DVTK_INSTALL_INCLUDE_DIR:PATH=include/vtk \
>     -DVTK_INSTALL_TCL_DIR=/usr/lib/tcl${_tkver}/vtk/ \
>     -DVTK_PYTHON_VERSION=3 \
>     -DPYTHON_EXECUTABLE=/usr/bin/python3 \
>     -DPYTHON_INCLUDE_DIR=/usr/include/python3.5m \
>     -DPYTHON_LIBRARY=/usr/lib/libpython3.5m.so \
>     -DVTK_USE_SYSTEM_HDF5=OFF \
>     ${cmake_system_flags} \
>     -DCMAKE_BUILD_TYPE=Release \
>     "${srcdir}/VTK-$pkgver" \
>     -GNinja
>
> and so uses the OpenGL2 backend.
>
> But you're saying this shouldn't really work?
>
> Elvis
>
>
>>
>> Ken
>>
>>
>>
>>
>> On Mon, Jul 11, 2016 at 3:54 PM, Elvis Stansvik <
>> elvis.stansvik at orexplore.com> wrote:
>>
>>> I now have a minimal example I can share:
>>>
>>>     https://drive.google.com/open?id=0B1a2u6qVxaL7S2d3OF9uR3Q2amc
>>>
>>> This is an AppImage (hello.appimage), built just the way I build my
>>> application. It shows a sphere in a QVTKWidget. The download is 62 MB since
>>> the VTK bundled in the image includes debugging symbols.
>>>
>>> It would be great if other people could download and execute the image
>>> on their distros, to see if it runs. I've tested it only on Kubuntu 16.04
>>> (where it works) and Arch Linux (where it crashes like described in
>>> previous mails).
>>>
>>> Specifically it would be _very_ interesting if someone with
>>>
>>> 1. Arch Linux, or
>>> 2. a somewhat old Intel graphics chipset, or (even better)
>>> 3. both of the above,
>>>
>>> could try running it, and see if they can reproduce my crash (failure to
>>> initialize GLEW).
>>>
>>> I'm attaching the sources and scripts (hello.tar.gz) from which I built
>>> this example. If you want to build it yourself, just type "make" in the
>>> extracted directory. All you need is Docker and Make, everything else is
>>> taken care of inside a CentOS 6 Docker container.
>>>
>>> Many thanks in advance.
>>>
>>> Elvis
>>>
>>> 2016-07-11 17:27 GMT+02:00 Elvis Stansvik <elvis.stansvik at orexplore.com>
>>> :
>>>
>>>> Hi all,
>>>>
>>>> In exploring different deployment options, I'm now trying to create an
>>>> AppImage of a VTK+Qt application. For those who don't know, AppImage is a
>>>> packaging format where the application, including (almost) all of its
>>>> dependencies are put into a self-extracting ISO image called an AppImage.
>>>>
>>>> Doing this takes quite a bit of manual work, but if you do things
>>>> correctly and build the image on a good base system (I'm using CentOS 6),
>>>> the image should run on a multitude of distros.
>>>>
>>>> I've had some success: The resulting image runs on e.g. Ubuntu Xenial.
>>>>
>>>> I'm now trying it on my Arch Linux laptop (not a common/easy target for
>>>> AppImages, but I'd like to make it work since I run it personally), and get:
>>>>
>>>> ERROR: In /tmp/VTK-7.0.0/Rendering/OpenGL2/vtkOpenGLRenderWindow.cxx,
>>>> line 533
>>>> vtkXOpenGLRenderWindow (0x1e48140): GLEW could not be initialized.
>>>>
>>>> This is due to a glewInit() call failing during initialization of the
>>>> render window, and I've debugged it to the underlying call to
>>>> glGetString(GL_VERSION) in VTK's forked GLEW library returning NULL.
>>>>
>>>> Does anyone have an idea why this might happen? The VTK I'm using here
>>>> is configured as follows:
>>>>
>>>> cmake3 \
>>>>     -DCMAKE_INSTALL_PREFIX=/usr \
>>>>     -DVTK_Group_Qt=ON \
>>>>     -DVTK_QT_VERSION=5 \
>>>>     -DVTK_Group_Imaging=ON \
>>>>     -DVTK_Group_Views=ON \
>>>>     -DVTK_Group_MPI=OFF \
>>>>     -DVTK_Group_Tk=OFF \
>>>>     -DVTK_Group_Web=OFF \
>>>>     -DBUILD_TESTING=OFF \
>>>>     -DVTK_USE_SYSTEM_LIBRARIES=ON \
>>>>     -DVTK_USE_SYSTEM_LIBPROJ4=OFF \
>>>>     -DCMAKE_BUILD_TYPE=Debug \
>>>>     ..
>>>>
>>>> And it uses the OpenGL2 backend.
>>>>
>>>> It was built inside a CentOS 6 Docker container on a Kubuntu 16.04 host
>>>> with HD 4400 Intel graphics adapter. The target system is an older laptop
>>>> with up-to-date Arch Linux and a weaker HD 3000 Intel graphics adapter.
>>>>
>>>> Now, packaging apps that use OpenGL is a bit tricky, because you can't
>>>> bundle e.g. libX11, libGL and some other libraries that are dependant on
>>>> the user's graphics adapter/environment.
>>>>
>>>> The libraries that I've chosen to _not_ bundle are:
>>>>
>>>>     libz.so.1
>>>>     libm.so.6
>>>>     libSM.so.6
>>>>     libICE.so.6
>>>>     libX11.so.6
>>>>     libXext.so.6
>>>>     libXt.so.6
>>>>     libstdc++.so.6
>>>>     libgcc_s.so.1
>>>>     libc.so.6
>>>>     libpthread.so.0
>>>>     librt.so.1
>>>>     libGL.so.1
>>>>     libdl.so.2
>>>>     libuuid.so.1
>>>>     libxcb.so.1
>>>>     libxcb-dri3.so.0
>>>>     libxcb-present.so.0
>>>>     libxcb-randr.so.0
>>>>     libxcb-xfixes.so.0
>>>>     libxcb-render.so.0
>>>>     libxcb-shape.so.0
>>>>     libxcb-sync.so.1
>>>>     libxshmfence.so.1
>>>>     libglapi.so.0
>>>>     libXdamage.so.1
>>>>     libXfixes.so.3
>>>>     libX11-xcb.so.1
>>>>     libxcb-glx.so.0
>>>>     libxcb-dri2.so.0
>>>>     libXxf86vm.so.1
>>>>     libdrm.so.2
>>>>     libXau.so.6
>>>>     libXdmcp.so.6
>>>>
>>>> This may be a little too liberal, and it could be that I should be
>>>> bundling some of these. But it seems to work fine since the AppImage runs
>>>> without problem on Kubuntu 16.04.
>>>>
>>>> The application also runs fine if I build VTK and the application
>>>> "normally" on the Arch host and run it (using OpenGL2 backend), so the
>>>> graphics adapter should be capable enough. It's just when I try to run the
>>>> CentOS 6-built AppImage on the Arch host that it fails.
>>>>
>>>> The application essentially just creates a QVTKWidget and renders a
>>>> volume into its rendering window.
>>>>
>>>> I saw that one (perhaps likely?) reason for glGetString(GL_VERSION)
>>>> returning NULL is that initialization of the GL context failed (or wasn't
>>>> fully done yet). If this is the case, does anyone know where I can debug
>>>> this further in VTK? Where is the OpenGL context in VTK set up when using
>>>> QVTKWidget + OpenGL2 backend?
>>>>
>>>> Finally: Has anyone else tried packaging VTK applications as AppImages?
>>>>
>>>> I know ParaView is provided as a prebuilt Linux binary with VTK
>>>> bundled, so I can imagine the ParaView folks has ran into some issues like
>>>> this?
>>>>
>>>> Thanks in advance for any advice.
>>>>
>>>> Elvis
>>>>
>>>
>>>
>>> _______________________________________________
>>> Powered by www.kitware.com
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> Please keep messages on-topic and check the VTK FAQ at:
>>> http://www.vtk.org/Wiki/VTK_FAQ
>>>
>>> Search the list archives at: http://markmail.org/search/?q=vtkusers
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://public.kitware.com/mailman/listinfo/vtkusers
>>>
>>>
>>
>>
>> --
>> Ken Martin PhD
>> Chairman & CFO
>> Kitware Inc.
>> 28 Corporate Drive
>> Clifton Park NY 12065
>> 518 371 3971
>>
>> This communication, including all attachments, contains confidential and
>> legally privileged information, and it is intended only for the use of the
>> addressee.  Access to this email by anyone else is unauthorized. If you are
>> not the intended recipient, any disclosure, copying, distribution or any
>> action taken in reliance on it is prohibited and may be unlawful. If you
>> received this communication in error please notify us immediately and
>> destroy the original message.  Thank you.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtkusers/attachments/20160711/471bbdab/attachment.html>