Bug 226244 - [WPE][GTK] Support building against uClibc
Summary: [WPE][GTK] Support building against uClibc
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Tools / Tests (show other bugs)
Version: WebKit Local Build
Hardware: Unspecified Linux
: P2 Normal
Assignee: Adrian Perez
URL:
Keywords: InRadar
Depends on: 210068 225099
Blocks:
  Show dependency treegraph
 
Reported: 2021-05-25 15:31 PDT by Adrian Perez
Modified: 2021-06-01 06:40 PDT (History)
13 users (show)

See Also:


Attachments
Patch (2.94 KB, patch)
2021-05-25 15:37 PDT, Adrian Perez
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Adrian Perez 2021-05-25 15:31:31 PDT
After the fixes from bug #210068 and bug #225099 it's *almost*
possible to build the GTK and WPE ports against uClibc—the Musl
fixes also benefited uClibc :)

There are a couple of things to fix for uClibc, though.
Comment 1 Adrian Perez 2021-05-25 15:37:54 PDT
Created attachment 429702 [details]
Patch
Comment 2 Michael Catanzaro 2021-06-01 05:27:55 PDT
Comment on attachment 429702 [details]
Patch

Unfortunately we're almost guaranteed to have unknown glibc-specific assumptions that will result in incorrect behavior at runtime hidden throughout WebKit. I guess the first step to finding them is to make it build.

E.g. one fun problem we used to have was gspawn relied on malloc being async-signal-safe, so subprocess launching would randomly fail with other C libraries , but only if you're sufficiently unlucky. That was eventually fixed in fairly recent versions of glib. Point is: similar problems will be out there....
Comment 3 EWS 2021-06-01 06:01:09 PDT
Committed r278302 (238339@main): <https://commits.webkit.org/238339@main>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 429702 [details].
Comment 4 Radar WebKit Bug Importer 2021-06-01 06:02:20 PDT
<rdar://problem/78711308>
Comment 5 Adrian Perez 2021-06-01 06:40:41 PDT
(In reply to Michael Catanzaro from comment #2)
> Comment on attachment 429702 [details]
> Patch
> 
> Unfortunately we're almost guaranteed to have unknown glibc-specific
> assumptions that will result in incorrect behavior at runtime hidden
> throughout WebKit. I guess the first step to finding them is to make it
> build.
> 
> E.g. one fun problem we used to have was gspawn relied on malloc being
> async-signal-safe, so subprocess launching would randomly fail with other C
> libraries , but only if you're sufficiently unlucky. That was eventually
> fixed in fairly recent versions of glib. Point is: similar problems will be
> out there....

While I had *not* done a full run of layout tests with an uClibc build,
I did submit this patch to Buildroot and did an ARM64 build which I smoke
tested for a while without issues. The recent changes that were done for
Musl also helped for uClibc, as a matter of fact, and while it is likely
that some tests would fail with an uClibc build, it seems usable in practice.

Here's the Buildroot patches needed to have the WPE and GTK ports built
with uClibc, for reference:

  https://patchwork.ozlabs.org/project/buildroot/patch/20210526182416.2798443-1-aperez@igalia.com/
  https://patchwork.ozlabs.org/project/buildroot/patch/20210526183839.3062697-1-aperez@igalia.com/

:)