[vtkusers] AppImage packaging: GLEW could not be initialized
Elvis Stansvik
elvis.stansvik at orexplore.com
Mon Jul 11 16:33:22 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
>
I can confirm that this one is returning a 0 ContextId :( It makes me
wonder why it works if I build + run on the target, but not when I run my
AppImage-packaged version (which is built on CentOS 6 and includes a
bundled VTK, similarly built). Ideas for debugging further are greatly
appreciated.
Elvis
>
> in vtkXOpenGLRenderWindow.cxx.
>
>
> 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.
>
> 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/badd308d/attachment.html>
More information about the vtkusers
mailing list