Summary: | Build failure after r240431 | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Pablo Saavedra <psaavedra> | ||||||||||
Component: | WPE WebKit | Assignee: | Pablo Saavedra <psaavedra> | ||||||||||
Status: | RESOLVED FIXED | ||||||||||||
Severity: | Normal | CC: | ajacoutot, aperez, bugs-noreply, cgarcia, commit-queue, ews-watchlist, keith_miller, mark.lam, mcatanzaro, msaboff, psaavedra, saam, webkit-bug-importer, zan | ||||||||||
Priority: | P2 | ||||||||||||
Version: | WebKit Local Build | ||||||||||||
Hardware: | Other | ||||||||||||
OS: | Linux | ||||||||||||
Attachments: |
|
Description
Pablo Saavedra
2019-02-06 00:48:06 PST
On systems using the GNU C Library, this will be unsigned int or unsigned long int. Ref: https://www.gnu.org/software/libc/manual/html_node/Important-Data-Types.html this patch works but I guess it is just a workaround: ``` diff --git a/Source/JavaScriptCore/API/glib/JSCOptions.cpp b/Source/JavaScriptCore/API/glib/JSCOptions.cpp index a9dc7e6c683..8dddffd42c5 100644 --- a/Source/JavaScriptCore/API/glib/JSCOptions.cpp +++ b/Source/JavaScriptCore/API/glib/JSCOptions.cpp @@ -73,6 +73,7 @@ static void valueToGValue(int32_t value, GValue* gValue) g_value_set_int(gValue, value); } +#if !CPU(ARM_THUMB2) && !CPU(ARM64) static bool valueFromGValue(const GValue* gValue, unsigned& value) { value = g_value_get_uint(gValue); @@ -83,6 +84,7 @@ static void valueToGValue(unsigned value, GValue* gValue) { g_value_set_uint(gValue, value); } +#endif static bool valueFromGValue(const GValue* gValue, size_t& value) { @@ -540,10 +542,12 @@ static JSCOptionType jscOptionsType(int) return JSC_OPTION_INT; } +#if !CPU(ARM_THUMB2) && !CPU(ARM64) static JSCOptionType jscOptionsType(unsigned) { return JSC_OPTION_UINT; } +#endif static JSCOptionType jscOptionsType(size_t) { ``` Maybe this one is more likely: ``` diff --git a/Source/JavaScriptCore/API/glib/JSCOptions.cpp b/Source/JavaScriptCore/API/glib/JSCOptions.cpp index a9dc7e6c683..222ca13e873 100644 --- a/Source/JavaScriptCore/API/glib/JSCOptions.cpp +++ b/Source/JavaScriptCore/API/glib/JSCOptions.cpp @@ -73,6 +73,7 @@ static void valueToGValue(int32_t value, GValue* gValue) g_value_set_int(gValue, value); } +#if CPU(ADDRESS64) static bool valueFromGValue(const GValue* gValue, unsigned& value) { value = g_value_get_uint(gValue); @@ -83,6 +84,7 @@ static void valueToGValue(unsigned value, GValue* gValue) { g_value_set_uint(gValue, value); } +#endif static bool valueFromGValue(const GValue* gValue, size_t& value) { @@ -540,10 +542,12 @@ static JSCOptionType jscOptionsType(int) return JSC_OPTION_INT; } +#if CPU(ADDRESS64) static JSCOptionType jscOptionsType(unsigned) { return JSC_OPTION_UINT; } +#endif static JSCOptionType jscOptionsType(size_t) { ``` Created attachment 361281 [details]
patch
Comment on attachment 361281 [details] patch Clearing flags on attachment: 361281 Committed r241014: <https://trac.webkit.org/changeset/241014> All reviewed patches have been landed. Closing bug. Hi. This patch broke webkitgtk build on OpenBSD i386 (builds fine on amd64). Source/JavaScriptCore/API/glib/JSCOptions.cpp:179:17: error: no matching function for call to 'valueFromGValue' (In reply to Antoine Jacoutot from comment #7) > Hi. > > This patch broke webkitgtk build on OpenBSD i386 (builds fine on amd64). > > Source/JavaScriptCore/API/glib/JSCOptions.cpp:179:17: error: no matching > function for call to 'valueFromGValue' Could you provide the full log output for this error? (In reply to Pablo Saavedra from comment #8) > (In reply to Antoine Jacoutot from comment #7) > > Hi. > > > > This patch broke webkitgtk build on OpenBSD i386 (builds fine on amd64). > > > > Source/JavaScriptCore/API/glib/JSCOptions.cpp:179:17: error: no matching > > function for call to 'valueFromGValue' > > > Could you provide the full log output for this error? Sure things. I'm attaching it since it's a big long. Created attachment 365354 [details]
openbsd i386 build failure
Created attachment 365853 [details]
new patch
could you try with applying this patch (new patch)?
Hi Pablo. Thanks for the patch. Unfortunately that didn't fix all failures. See new-patch.log. Created attachment 365855 [details]
OpenBSD i386 new-patch failure log
It also broke s390 (not s390x, but old 32-bit s390). It seems size_t there is 64-bit (???) even though pointers are 32-bit? That's... very strange. I don't have a solution to propose and don't plan to fix this upstream (I will add a hack to our RHEL 7 package; we don't support s390 anymore in RHEL 8), just adding a comment here for historical interest.... (In reply to Michael Catanzaro from comment #14) > It also broke s390 (not s390x, but old 32-bit s390). It seems size_t there > is 64-bit (???) even though pointers are 32-bit? That's... very strange. Ah, I think size_t is actually 'long unsigned int', so it's 32-bit, but different from vanilla unsigned int. Pablo actually anticipated this in comment #1. :) |