[vtkusers] AppImage packaging: GLEW could not be initialized

Mon Jul 11 16:14:53 EDT 2016

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 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/8c31b71f/attachment.html>