Bug#1020640: libglew2.2: Glew built without, wxwidgets with EGL support

[Andreas Metzler]

Package: libglew2.2
Version: 2.2.0-4
Severity: important
X-Debbugs-Cc: libwxba...@packages.debian.org, hu...@debian.org

Hello,

wxwidgets and glew disagree over EGL support, glew is built without,
wxwidgets (since 3.2) with.

That causes problems (crashes, "Unable to init glew library") in
software using glew and wxwidgets. Google finds multiple instances, I
know about hugin.

While I have submitted this against glew and Cc'd wxwidgets maintainers
I do not know whether the proper solution is for building glew with EGL
or for building wxwidgets with --disable-glcanvasegl.

cu Andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

[Olly Betts]

On Sat, Sep 24, 2022 at 06:09:31PM +0200, Andreas Metzler wrote:
> wxwidgets and glew disagree over EGL support, glew is built without,
> wxwidgets (since 3.2) with.
>
> That causes problems (crashes, "Unable to init glew library") in
> software using glew and wxwidgets. Google finds multiple instances, I
> know about hugin.
>
> While I have submitted this against glew and Cc'd wxwidgets maintainers
> I do not know whether the proper solution is for building glew with EGL
> or for building wxwidgets with --disable-glcanvasegl.

AIUI, wxWidgets needs EGL for wxGLCanvas to work under Wayland.

With 3.0, we had a hack in place to force use of X11 if the wx GL
library was loaded:

https://sources.debian.org/src/wxwidgets3.0/3.0.5.1%2Bdfsg-5/debian/patches/force-x11-for-wxgl.patch/

That was better than not working, but doesn't seem a desirable long term
solution.

Cheers,
Olly

[Olly Betts]

On Sat, Sep 24, 2022 at 09:50:10PM +0100, Olly Betts wrote:
> On Sat, Sep 24, 2022 at 06:09:31PM +0200, Andreas Metzler wrote:
> > wxwidgets and glew disagree over EGL support, glew is built without,
> > wxwidgets (since 3.2) with.
> >
> > That causes problems (crashes, "Unable to init glew library") in
> > software using glew and wxwidgets. Google finds multiple instances, I
> > know about hugin.

FWIW, these are the packages which seem to depend on both wx and glew
(just based on checking dependencies):

hugin
megaglest
qutemol
scorched3d
darkradiant
limesuite

The last two have already switched to wx3.2 in unstable and testing, but
I don't see reports in the BTS of glew-related problems, and didn't see
any issues from a quick test myself. At least with darkradiant I did
get what looked like a GL rendered pane to appear - I'm not sure I
actually exercised any GL code with limesuite (it seems to need some
hardware I don't have to be useful).

Cheers,
Olly

[Alastair McKinstry]

Hi,


As maintainer would be open to changing Glew to EGL support, but need to
understand better the consequences.

I have a test build of glew with egl (for Linux, not hurd or freebsd
yet) and it builds fine.

Any pointers to docs on EGL/non-EGL builds, or opinions and evidence
would be welcome.


Alastair

--
Alastair McKinstry,
GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5
ph: +353 87 6847928 e: alas...@sceal.ie, im: @sceal.ie:mckinstry

[Andreas Metzler]

On 2022-10-03 Alastair McKinstry <alastair....@sceal.ie> wrote:
> Hi,


> As maintainer would be open to changing Glew to EGL support, but need to
> understand better the consequences.

> I have a test build of glew with egl (for Linux, not hurd or freebsd yet)
> and it builds fine.

> Any pointers to docs on EGL/non-EGL builds, or opinions and evidence would
> be welcome.

[...]

With hugin opening hugin and klicking on the [GL] icon yields
ERROR: 13:32:20.593540 (./src/hugin1/hugin/GLViewer.cpp:133) SetUpContext(): Error initialising GLEW: Unknown error.

Klicking once more seems to succeed.

I have tried rebuilding glew with
--- a/debian/rules
+++ b/debian/rules
@@ -34,7 +34,7 @@ override_dh_auto_build:
GLUT_LDFLAGS=-lglut \
LIBDIR=/usr/lib/$(DEB_HOST_MULTIARCH) \
'LD=$$(CC)' \
- SYSTEM=$(firstword $(subst -, ,$(DEB_HOST_GNU_SYSTEM))) \
+ SYSTEM=$(firstword $(subst -, ,$(DEB_HOST_GNU_SYSTEM)))-egl \

But I am not sure that actually works, since the symbol list is
unchanged. The hugin behavior also does not change with this glew
rebuild.

I suspect glew upstream just is not ready yet:
Afaict fedora does build with EGL suppport and OpenSuse has dropped it
again:
| * Sat Aug 21 2021 Atri Bhattacharya <badsh...@gmail.com>
| - Revert building with EGL support, as it breaks mutliple apps
| (boo#1189524).
There is known breakage on the glew side:
https://github.com/nigels-com/glew/issues/321
https://github.com/nigels-com/glew/issues/315

Archlinux builds with EGL but does some patching
https://archlinuxarm.org/packages/armv7h/glew/files

(Applying the patch to the Debian package yielded a FTBFS)

cu Andreas

[Andreas Metzler]

Control: block 1023279 by 1020640

On 2022-10-10 Andreas Metzler <amet...@bebt.de> wrote:
> On 2022-10-03 Alastair McKinstry <alastair....@sceal.ie> wrote:
> > As maintainer would be open to changing Glew to EGL support, but need to
> > understand better the consequences.

[...]

Mandriva also enables glew egl but pulls a patchset from glew GIT head
https://github.com/OpenMandrivaAssociation/glew/tree/master and indeed
if I build glew GIT head (egl build, i.e. SYSTEM=linux-egl) and run
hugin against it it just works and does not crash.

[Scott Talbert]

On Sat, 5 Nov 2022, Andreas Metzler wrote:

>> On 2022-10-03 Alastair McKinstry <alastair....@sceal.ie> wrote:
>>> As maintainer would be open to changing Glew to EGL support, but need to
>>> understand better the consequences.
>
> [...]
>
> Mandriva also enables glew egl but pulls a patchset from glew GIT head
> https://github.com/OpenMandrivaAssociation/glew/tree/master and indeed
> if I build glew GIT head (egl build, i.e. SYSTEM=linux-egl) and run
> hugin against it it just works and does not crash.

Thanks Andreas for your work testing out glew with EGL support.

I'm coming to the realization, though, that wxWidgets EGL-only wxGLCanvas
may not be ready for prime time, given this challenge and several other
bugs (slic3r-prusa, pronterface, etc). Thus, I'm leaning towards
rebuilding wxWidgets with GLX support (and adding back our force-X11 so
things don't break on Wayland patch). The one challenge with this is that
it will break ABI and thus will require rebuilding all packages that link
with the libwx-gl library.

Any comments or concerns?

Thanks,
Scott