[wpe-webkit] What causes symbols to be visible?

Salisbury, Mark mark.salisbury at hp.com
Mon Aug 6 14:36:14 PDT 2018

It was more work than I expected it to be.  We have about 50 commits on a branch, a few of the commits are not small.

This isn't all the changes but gives a feel -

Build WPE on Windows
1.	Add some build scripts to use vcpkg (google 'vcpkg' for more info) to build WPE webkit dependencies (ICU, glib, cairo, freetype, etc.)
2.	Add some win specific .h files in WTF_PUBLIC_HEADERS
3.	Changes in some places to use OS(WINDOWS) instead of PLATFORM(WINDOWS)
4.	Force early include of <glib/gi18n-lib.h> (libintl/gettext lib has macros for common *printf routines, breaking PrintStream.h, etc.), then undefine fprintf, vfprintf, printf, etc. defined in libintl/gettext.  Not sure why this isn't a problem for non-Windows platforms.  Maybe GCC preprocessor doesn't match macros to identifiers prefixed with scope operator?  (MyClass::printf)
5.	Changes to compile with more recent ICU version for Windows code
6.	Make WPE WebKit on Windows use OpenGL like other platforms do; build ANGLE like other platforms do (OpenGL provided by ANGLE in vcpkg dependencies) 
7.	Some cmake changes to make build cross-platform (add macro for creating a symbolic links, use/find glib-compile-resources, glib-mkenums in cross platform way)
8.	Windows implementation for Source/WebKit/NetworkProcess/cache
9.	Changed SharedMemoryWin.cpp, made AttachmentWin.cpp a bit more like AttachmentUnix.cpp, fixing "FIXME: This code is duplicated with SharedMemory::Handle implementation for Win"
10.	Implement Native Visualizer to improve debugging with Visual Studio
11.	[Windows][WPE] Disable WEBDRIVER.  It exposes a MS compiler bug.  Plan to submit a bug report but don't have a good bug jar yet.

Build without certain features enabled
1.	Added cmake option to enable/disable GSTREAMER in build
2.	Fixes for compiling without MEDIA_SOURCE
3.	Changes to build without CONTEXT_MENUS, MHTML (some features we didn't need enabled)

General WPE/glib changes
1.	RunLoopGLib.cpp - prevent UI hangs
Put in workaround to prevent hang.  See https://bugzilla.gnome.org/show_bug.cgi?id=761102#c46
2.	WPEView.cpp - [WPE] Dispatch mouse events on main thread
I noticed that WebPageProxy accesses a Deque named m_mouseEventQueue.  Deque objects do not take locks; modifications to m_mouseEventQueue on multiple threads (or even modifications and accesses) by multiple threads are not safe.

Then of course I added another backend to WPEBackend-rdk for Windows.

I'd like to clean up a few things and push to my GitHub fork.  If it looks worthwhile to folks we could start creating bugs/patches to upstream work.

Of course we'll have more changes coming in the future too, some of which would be worth upstreaming.  I found a nasty memory leak earlier this year when using ACCESSIBILITY with a particular type of page.  It did not appear fixed upstream...


-----Original Message-----
From: Michael Catanzaro <mcatanzaro at igalia.com> 
Sent: Monday, August 6, 2018 9:47 AM
To: Salisbury, Mark <mark.salisbury at hp.com>
Cc: Adrian Perez de Castro <aperez at igalia.com>; webkit-wpe at lists.webkit.org
Subject: Re: [wpe-webkit] What causes symbols to be visible?

On Mon, Aug 6, 2018 at 10:02 AM, Salisbury, Mark <mark.salisbury at hp.com> wrote:
> I expect we'll be moving to the new API before long.  I'd like to be 
> more engaged in pushing work upstream too.  One important thing for us 
> - running on Windows.  We have WPE running on Windows and Linux.
> We have a Windows simulator that's important to us.  I know this 
> wasn't of too much interest to you guys earlier, but I think that the 
> work we're doing overlaps with what folks at Sony are doing too, 
> bringing back WK2 on Windows.

I'd be personally quite interested in seeing how much effort it was to port WPE to Windows. I never imagined it would be ported to that environment! I imagine you must have a substantial number of downstream changes to make it work?


More information about the webkit-wpe mailing list