[Webkit-unassigned] [Bug 222959] [CMake] Build fails on RISC-V with GCC 11

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu Mar 11 15:23:27 PST 2021


https://bugs.webkit.org/show_bug.cgi?id=222959

--- Comment #19 from Khem Raj <raj.khem at gmail.com> ---
(In reply to Carlos Alberto Lopez Perez from comment #17)
> Comment on attachment 422956 [details]
> potential fix 3
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=422956&action=review
> 
> > Source/WebKit/ChangeLog:4
> > +        Use renamed ATOMICS_REQUIRE_LIBATOMIC instead of
> > +       ATOMIC_INT64_REQUIRES_LIBATOMIC.
> 
> We don't usually wrap long lines on WebKit. The practice is to use just one
> line for all the subject even if this is many characters long.

Done.

> 
> > Source/WebKit/ChangeLog:6
> > +
> > +        https://bugs.webkit.org/show_bug.cgi?id=222959
> 
> Also we don't use an extra empty line between the subjet and the bug link

Thanks done, I generated them but then edited them heavily :)

> 
> > Source/WebKit/ChangeLog:8
> > +        Reviewed by OOPS.
> 
> This should be "Reviewed by NOBODY (OOPS!)."
> That is important because the tooling we use to land patches looks for those
> exact words to later replace the "NOBODY (OOPS!)" with the name of the
> reviewer.

Good to know. done.

> 
> I know this sounds like a lot of bureaucracy at first, but once you get used
> to it is pretty straightforward.
> 

yeah in the world after git, CHANGELOGs have become out of fashion but I know
few other projects who still use them.


> To generate the changelogs we have a script. We don't create them by hand.
> It is used like this:
> 
> Tools/Scripts/prepare-ChangeLog -b ${bugzillanumber} -g
> ${localgitcommitforchangelog}
> 
> For example, assuming you are checked out on the patch to upload and this
> patch is committed locally
> 
> Tools/Scripts/prepare-ChangeLog -b 222959 -g HEAD
> 
> It will generate the changelog files, then you just edit under the reviewed
> line it will appear the message of your local commit.. you edit that to tell
> a bit about what the patch does. Then you add the changelogs to git and
> commit them by amending the previos commit, then its ready to upload.
> 
> You can generate a patch and upload it here manually or you can use another
> script to upload the patch directly.
> 
> Tools/Scripts/webkit-patch upload -g ${localgitcommittobeuploaded}
> --suggest-reviewers

I think these python tools expect python to point to python2 or something like that, on my machine python points to python3, perhaps that's the issue but it does not work as expected. I manually changed the interpreter in one of these tools to call for python2 and it did lot better. 

> 
> It will automatically detect the bug number where the patch should be
> uploaded from the changelog
> 
> > Source/cmake/WebKitCompilerFlags.cmake:284
> >  if (COMPILER_IS_GCC_OR_CLANG)
> >      set(ATOMIC_TEST_SOURCE "
> > -        #include <atomic>
> > -        int main() { std::atomic<int64_t> i(0); i++; return 0; }
> > +	#include <atomic>
> > +	int main() {
> > +          std::atomic<bool> y (false);
> > +          std::atomic<uint64_t> x (0);
> > +          bool expected = true;
> > +          bool j = y.compare_exchange_weak(expected,false);
> > +          x++;
> > +          return 0;
> > +        }
> 
> The Early Warning System (EWS) bot for checking the style is complaining
> here about mixed spaces/tabs
> 
> ERROR: Source/cmake/WebKitCompilerFlags.cmake:276:  Line contains tab
> character.  [whitespace/tab] [5]
> ERROR: Source/cmake/WebKitCompilerFlags.cmake:277:  Line contains tab
> character.  [whitespace/tab] [5]
> Total errors found: 2 in 8 files
> program finished with exit code 1

Fixes, my editor is as adamant as me :) usually its smart about indenting
and detects the style from sources, but in a CMakeFile embedding C++ code it
falls back to my defaults which causes these issues. 

Is there a way to run all EWS tests locally before submitting ?

> 
> ^^ https://ews-build.webkit.org/#/builders/6/builds/42334

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20210311/407204a5/attachment.htm>


More information about the webkit-unassigned mailing list