[vtkusers] AppImage packaging: GLEW could not be initialized
Elvis Stansvik
elvis.stansvik at orexplore.com
Wed Jul 13 04:55:09 EDT 2016
2016-07-12 17:36 GMT+02:00 Elvis Stansvik <elvis.stansvik at orexplore.com>:
> 2016-07-11 22:33 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
>>>
>>
>> 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.
>>
>
> After some more testing, where I've been running the image in various
> Docker containers on the build host (Ubuntu 16.04, Debian 8.5 and OpenSUSE
> 13.2 all worked), I ran into the crash again on Fedora 24. But note that
> this time it was running on the build host, which has Haswell graphics.
>
> So I'm suspecting the reason for the failure has something to do with
> library versions. Perhaps I'm too aggressive with excluding some things
> when I'm bundling the libraries, and that this causes issues on Arch and
> Fedora 24, since they have very recent library versions?
>
> The list of libraries I chose not to bundle is in my original mail. Anyone
> who can spot something they think I really should be bundling? I obviously
> can't bundle libX11 and libGL, but have I been to vigorous in excluding
> some of the other related libraries?
>
Okay, I finally have closure on this issue:
The problem on the Arch machine (the Sandybridge one with HD3000) had
nothing to do with its graphics capabilities:
https://bugs.archlinux.org/task/48994
In short: I can't ship a bundled libgcrypt, since it is depended on by both
the Qt plugins (which I must ship) and Mesa (which I can't ship), and the
version on Arch against which mesa was linked is too new to be compatible
with the one I was shipping. Solution: Don't ship libgcrypt. The app now
runs fine on the Arch machine.
It was running with LIBGL_DEBUG=verbose that revealed this as the cause:
libGL: OpenDriver: trying /usr/lib/xorg/modules/dri/tls/i965_dri.so
libGL: OpenDriver: trying /usr/lib/xorg/modules/dri/i965_dri.so
libGL: dlopen /usr/lib/xorg/modules/dri/i965_dri.so failed
(/usr/lib/libgcrypt.so.20: symbol gpgrt_lock_lock, version GPG_ERROR_1.0
not defined in file libgpg-error.so.0 with link time reference)
libGL error: unable to load driver: i965_dri.so
libGL error: driver pointer missing
libGL error: failed to load driver: i965
The problem on the Fedora machine, which I thought at first was the same
issue since the error was the same ("GLEW could not be initialized"), was a
simple PEBKAC: I had forgot to install mesa-dri-drivers in the Docker
container where I was testing. This was again revealed by running with
LIBGL_DEBUG=verbose:
libGL: OpenDriver: trying /usr/lib64/dri/tls/i965_dri.so
libGL: OpenDriver: trying /usr/lib64/dri/i965_dri.so
libGL: dlopen /usr/lib64/dri/i965_dri.so failed
(/usr/lib64/dri/i965_dri.so: cannot open shared object file: No such file
or directory)
libGL error: unable to load driver: i965_dri.so
libGL error: driver pointer missing
libGL error: failed to load driver: i965
Installing mesa-dri-drivers solved the issue and the the app is now running
fine on Fedora as well.
So all is well now!
I'm still interested in what you said about HD 3000 Ken, that it's not
supported by the OpenGL2 backend. Because here it seems to run fine
(although my test application is simple, it just renders a volume with
vtkGPUVolumeRayCastMapper). Can I expect trouble on this machine using
other parts of VTK?
Elvis
> Elvis
>
>
>>
>> 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/20160713/f492bca9/attachment.html>
More information about the vtkusers
mailing list