Bug 194330 - Build failure after r240431
Summary: Build failure after r240431
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WPE WebKit (show other bugs)
Version: WebKit Local Build
Hardware: Other Linux
: P2 Normal
Assignee: Pablo Saavedra
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-02-06 00:48 PST by Pablo Saavedra
Modified: 2020-06-17 16:19 PDT (History)
14 users (show)

See Also:


Attachments
patch (1.59 KB, patch)
2019-02-06 00:53 PST, Pablo Saavedra
no flags Details | Formatted Diff | Diff
openbsd i386 build failure (67.03 KB, text/plain)
2019-03-20 10:27 PDT, Antoine Jacoutot
no flags Details
new patch (1.33 KB, patch)
2019-03-25 01:15 PDT, Pablo Saavedra
no flags Details | Formatted Diff | Diff
OpenBSD i386 new-patch failure log (15.15 KB, text/plain)
2019-03-25 02:57 PDT, Antoine Jacoutot
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Pablo Saavedra 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
Comment 1 Pablo Saavedra 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
Comment 2 Pablo Saavedra 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)
 {
```
Comment 3 Pablo Saavedra 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)
 {
```
Comment 4 Pablo Saavedra 2019-02-06 00:53:00 PST
Created attachment 361281 [details]
patch
Comment 5 WebKit Commit Bot 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>
Comment 6 WebKit Commit Bot 2019-02-06 01:35:24 PST
All reviewed patches have been landed.  Closing bug.
Comment 7 Antoine Jacoutot 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'
Comment 8 Pablo Saavedra 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?
Comment 9 Antoine Jacoutot 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.
Comment 10 Antoine Jacoutot 2019-03-20 10:27:39 PDT
Created attachment 365354 [details]
openbsd i386 build failure
Comment 11 Pablo Saavedra 2019-03-25 01:15:25 PDT
Created attachment 365853 [details]
new patch

could you try with applying this patch (new patch)?
Comment 12 Antoine Jacoutot 2019-03-25 02:56:54 PDT
Hi Pablo.

Thanks for the patch. Unfortunately that didn't fix all failures.
See new-patch.log.
Comment 13 Antoine Jacoutot 2019-03-25 02:57:34 PDT
Created attachment 365855 [details]
OpenBSD i386 new-patch failure log
Comment 14 Michael Catanzaro 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....
Comment 15 Michael Catanzaro 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. :)