Bug 203956 – [GTK] WebKitGTK 2.26.x fails to build with ENABLE_WEBGL=OFF

• Status: RESOLVED
• Resolution: WONTFIX
• Component: WebKitGTK

[Haelwenn (lanodan) Monnier]

Created attachment 383048 [details]
webkit-gtk-2.26.2 build log

Compiling WebKitGTK 2.26.1 and 2.26.2 with -DENABLE_WEBGL=OFF fails with errors like ``FormatConverter.h:54:18: error: use of undeclared identifier 'GraphicsContext3D'``.

[Michael Catanzaro]

Nobody's responding to bug reports? :/

ENABLE_WEBGL is a private build flag, not supported for WebKitGTK. If you want to disable WebGL at build time, you need to use -DENABLE_OPENGL=OFF. There's also a runtime setting if you want to build with OpenGL support but leave WebGL disabled at runtime. It's currently disabled by default, but you should explicitly set that to false if you use it because the default could change in the future: bug #205335.

[Michael Catanzaro]

Also, I guess it's obvious that building with -DENABLE_BUBBLEWRAP_SANDBOX=OFF is not great, so maybe your goal is to disable all the security, but if not, see bug #205337 for a warning about -DUSE_SYSTEM_MALLOC=ON.

[Haelwenn (lanodan) Monnier]

Oh okay, didn't notice it was a private one, will use the runtime flag for controlling it (which is better anyway).

Building with bubblewrap disabled is controlled via ebuild USE flag so it's not hardcoded and yeah I should make it use bmalloc.

IIRC I have -DUSE_SYSTEM_MALLOC=ON because otherwise would be very prone to calling abort() (ouch! librairies shouldn't do that) when memory allocation would fail with `vm.overcommit_memory = 2` (ended up going back to `vm.overcommit_memory = 0`).

[Michael Catanzaro]

(In reply to Haelwenn (lanodan) Monnier from comment #3)
> IIRC I have -DUSE_SYSTEM_MALLOC=ON because otherwise would be very prone to
> calling abort() (ouch! librairies shouldn't do that) when memory allocation
> would fail with `vm.overcommit_memory = 2` (ended up going back to
> `vm.overcommit_memory = 0`).

Hm, nobody has reported this before.

Memory allocation failure is fatal by necessity. Consider that WebKit depends on GLib, and g_malloc() crashes the application on allocation failure. (GLib's g_malloc() just wraps glibc's malloc with a check to see if allocation failed, and a crash if so.) So no library or application that uses GLib can avoid crash on allocation failure.

I suppose it could be more likely to occur with bmalloc if bmalloc allocations memory in larger chunks than glibc does. If the difference is significant enough to encourage you to disable bmalloc, that would certainly be worth a separate bug report.

[Haelwenn (lanodan) Monnier]

(In reply to Michael Catanzaro from comment #4)
> I suppose it could be more likely to occur with bmalloc if bmalloc
> allocations memory in larger chunks than glibc does. If the difference is
> significant enough to encourage you to disable bmalloc, that would certainly
> be worth a separate bug report.

Done at bug 205346