RESOLVED FIXED Bug 194330
Build failure after r240431
https://bugs.webkit.org/show_bug.cgi?id=194330
Summary Build failure after r240431
Pablo Saavedra
Reported 2019-02-06 00:48:06 PST
WPE is not longer builtable for ARMv7: TUNE_FEATURES = "arm armv7a vfp thumb neon callconvention-hard" Error: /home/igalia/psaavedra/yocto-wandboard-wpe/builds/wandboard-mesa-wpe-nightly/tmp/work/armv7at2hf-neon-imx-poky-linux-gnueabi/wpewebkit/nightly-AUTOINC+8d87c59385-r0/git/Source/JavaScriptCore/API/glib/JSCOptions.cpp:87:13: error: redefinition of 'bool valueFromGValue(const GValue*, size_t&)' static bool valueFromGValue(const GValue* gValue, size_t& value) ^~~~~~~~~~~~~~~ /home/igalia/psaavedra/yocto-wandboard-wpe/builds/wandboard-mesa-wpe-nightly/tmp/work/armv7at2hf-neon-imx-poky-linux-gnueabi/wpewebkit/nightly-AUTOINC+8d87c59385-r0/git/Source/JavaScriptCore/API/glib/JSCOptions.cpp:76:13: note: 'bool valueFromGValue(const GValue*, unsigned int&)' previously defined here static bool valueFromGValue(const GValue* gValue, unsigned& value) ^~~~~~~~~~~~~~~ /home/igalia/psaavedra/yocto-wandboard-wpe/builds/wandboard-mesa-wpe-nightly/tmp/work/armv7at2hf-neon-imx-poky-linux-gnueabi/wpewebkit/nightly-AUTOINC+8d87c59385-r0/git/Source/JavaScriptCore/API/glib/JSCOptions.cpp:93:13: error: redefinition of 'void valueToGValue(size_t, GValue*)' static void valueToGValue(size_t value, GValue* gValue) ^~~~~~~~~~~~~ /home/igalia/psaavedra/yocto-wandboard-wpe/builds/wandboard-mesa-wpe-nightly/tmp/work/armv7at2hf-neon-imx-poky-linux-gnueabi/wpewebkit/nightly-AUTOINC+8d87c59385-r0/git/Source/JavaScriptCore/API/glib/JSCOptions.cpp:82:13: note: 'void valueToGValue(unsigned int, GValue*)' previously defined here static void valueToGValue(unsigned value, GValue* gValue) ^~~~~~~~~~~~~ /home/igalia/psaavedra/yocto-wandboard-wpe/builds/wandboard-mesa-wpe-nightly/tmp/work/armv7at2hf-neon-imx-poky-linux-gnueabi/wpewebkit/nightly-AUTOINC+8d87c59385-r0/git/Source/JavaScriptCore/API/glib/JSCOptions.cpp:548:22: error: redefinition of 'JSCOptionType jscOptionsType(size_t)' static JSCOptionType jscOptionsType(size_t) ^~~~~~~~~~~~~~ /home/igalia/psaavedra/yocto-wandboard-wpe/builds/wandboard-mesa-wpe-nightly/tmp/work/armv7at2hf-neon-imx-poky-linux-gnueabi/wpewebkit/nightly-AUTOINC+8d87c59385-r0/git/Source/JavaScriptCore/API/glib/JSCOptions.cpp:543:22: note: 'JSCOptionType jscOptionsType(unsigned int)' previously defined here static JSCOptionType jscOptionsType(unsigned) ^~~~~~~~~~~~~~ This error during the build happens since: commit a39285bfede3d35f4497b6a1e52eb87fde97cd8f Author: carlosgc@webkit.org <carlosgc@webkit.org@268f45cc-cd09-0410-ab3c-d52691b4dbfc> Date: Thu Jan 24 11:09:54 2019 +0000 [GLIB] Expose JavaScriptCore options in GLib public API https://bugs.webkit.org/show_bug.cgi?id=188742 Reviewed by Michael Catanzaro. Source/JavaScriptCore: Add new API to set, get and iterate JSC options. More references: * External link (issue): https://github.com/Igalia/meta-webkit/issues/65 * External ling (compile logs): https://gitlab-artifacts.s3.amazonaws.com/26/9b/269be52fa73e7fb2b7c67b1556958dba98cfe48530678548f6a42fa93dcb9090/2019_02_06/156941893/158220240/job.log?response-content-type=text/plain%3B%20charset%3Dutf-8&response-content-disposition=inline&X-Amz-Expires=600&X-Amz-Date=20190206T081126Z&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAJTOFWQ3GL4O3Q3FA/20190206/us-east-1/s3/aws4_request&X-Amz-SignedHeaders=host&X-Amz-Signature=8db0b5a272b06a472771ebf663242db7ca039bcda42b95ef2c08a31ab7cc4c0b
Attachments
patch (1.59 KB, patch)
2019-02-06 00:53 PST, Pablo Saavedra
no flags
openbsd i386 build failure (67.03 KB, text/plain)
2019-03-20 10:27 PDT, Antoine Jacoutot
no flags
new patch (1.33 KB, patch)
2019-03-25 01:15 PDT, Pablo Saavedra
no flags
OpenBSD i386 new-patch failure log (15.15 KB, text/plain)
2019-03-25 02:57 PDT, Antoine Jacoutot
no flags
Pablo Saavedra
Comment 1 2019-02-06 00:48:19 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
Pablo Saavedra
Comment 2 2019-02-06 00:48:44 PST
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) { ```
Pablo Saavedra
Comment 3 2019-02-06 00:50:49 PST
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) { ```
Pablo Saavedra
Comment 4 2019-02-06 00:53:00 PST
WebKit Commit Bot
Comment 5 2019-02-06 01:35:22 PST
Comment on attachment 361281 [details] patch Clearing flags on attachment: 361281 Committed r241014: <https://trac.webkit.org/changeset/241014>
WebKit Commit Bot
Comment 6 2019-02-06 01:35:24 PST
All reviewed patches have been landed. Closing bug.
Antoine Jacoutot
Comment 7 2019-03-19 05:49:49 PDT
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'
Pablo Saavedra
Comment 8 2019-03-20 10:07:32 PDT
(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?
Antoine Jacoutot
Comment 9 2019-03-20 10:27:13 PDT
(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.
Antoine Jacoutot
Comment 10 2019-03-20 10:27:39 PDT
Created attachment 365354 [details] openbsd i386 build failure
Pablo Saavedra
Comment 11 2019-03-25 01:15:25 PDT
Created attachment 365853 [details] new patch could you try with applying this patch (new patch)?
Antoine Jacoutot
Comment 12 2019-03-25 02:56:54 PDT
Hi Pablo. Thanks for the patch. Unfortunately that didn't fix all failures. See new-patch.log.
Antoine Jacoutot
Comment 13 2019-03-25 02:57:34 PDT
Created attachment 365855 [details] OpenBSD i386 new-patch failure log
Michael Catanzaro
Comment 14 2020-06-17 16:15:36 PDT
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....
Michael Catanzaro
Comment 15 2020-06-17 16:19:52 PDT
(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. :)
Note You need to log in before you can comment on or make changes to this bug.