Hello Michael,

On Tue, 31 May 2022 11:14:57 +0200 Michael Nosthoff via buildroot <buildroot@buildroot.org> wrote:
 
> On Tuesday, May 31, 2022 00:18 CEST, Adrian Perez de Castro <aperez@igalia.com> wrote:
> 
> > Hello Michael,
> > 
> > On Tue, 24 May 2022 12:25:51 +0200 Michael Nosthoff via buildroot <buildroot@buildroot.org> wrote:
> >  
> > > 
> > > I just tested the 2022.05-rc1 + this patch with my config.
> > > 
> > > The patch solved the X11 headers build error but I'm getting two other errors.
> > > 
> > > (This applies to 2.36.1 as well as 2.36.2, both patched)
> > > 
> > > The first one "disappears" when I issue "make wpewebkit" a second time, so I guess this
> > > is a concurrency issue in the build setup:
> > > 
> > > [ 39%] Built target JavaScriptCore_CopyPrivateHeaders
> > > Scanning dependencies of target jsc
> > > make[4]: *** No rule to make target 'Source/JavaScriptCore/CMakeFiles/LowLevelInterpreterLib.dir/llint/LowLevelInterpreter.cpp.o', needed by 'bin/jsc'.  Stop.
> > > make[4]: *** Waiting for unfinished jobs....
> > > [ 39%] Building CXX object Source/JavaScriptCore/shell/CMakeFiles/jsc.dir/__/jsc.cpp.o
> > > make[3]: *** [CMakeFiles/Makefile2:794: Source/JavaScriptCore/shell/CMakeFiles/jsc.dir/all] Error 2
> > > make[3]: *** Waiting for unfinished jobs....
> > > Scanning dependencies of target LowLevelInterpreterLib
> > > [ 39%] Building CXX object Source/JavaScriptCore/CMakeFiles/LowLevelInterpreterLib.dir/llint/LowLevelInterpreter.cpp.o
> > > [ 39%] Built target LowLevelInterpreterLib
> > > [ 39%] Built target WebInspectorUI
> > > make[2]: *** [Makefile:171: all] Error 2
> > > 
> > > and the build ultimately then later fails with this error:
> > > 
> > > [ 48%] Building CXX object Source/WebCore/CMakeFiles/WebCore.dir/__/__/WebCore/DerivedSources/unified-sources/UnifiedSource-cbdfe323-42.cpp.o
> > > In file included from platform/graphics/filters/FESpecularLighting.h:25,
> > >                  from svg/SVGFESpecularLightingElement.h:25,
> > >                  from ../../WebCore/DerivedSources/JSSVGFESpecularLightingElement.h:26,
> > >                  from ../../WebCore/DerivedSources/JSSVGFESpecularLightingElement.cpp:22,
> > >                  from ../../WebCore/DerivedSources/unified-sources/UnifiedSource-3a52ce78-119.cpp:5:
> > > platform/graphics/filters/FELighting.h:72:41: error: ‘LightingData’ does not name a type
> > >    72 |     inline void platformApplyNeon(const LightingData&, const LightSource::PaintingData&);
> > >       |                                         ^~~~~~~~~~~~
> > > make[4]: *** [Source/WebCore/CMakeFiles/WebCore.dir/build.make:5152: Source/WebCore/CMakeFiles/WebCore.dir/__/__/WebCore/DerivedSources/unified-sources/UnifiedSource-3a52ce78-119.cpp.o] Error 1
> > > 
> > > I tried to find it in the webkit bugtracker but was not successful. 
> > 
> > We have had a few bugs related to the filters code in the past when
> > targeting 32-bit ARM, specially the NEON fast-paths which do not get
> > regularly built by buildbots on each WebKit commit.
> > 
> > > My WPE defconfig is 
> > > 
> > > BR2_PACKAGE_WPEWEBKIT=y
> > > BR2_PACKAGE_WPEWEBKIT_SANDBOX=y
> > > 
> > > with the arm gcc 10.3 toolchain.
> > 
> > Can you confirm that you are targeting some 32-bit ARM processor? If
> > yes, does it have NEON support? Alternatively, if you can share a
> > .config, or use “make savedefconfig” and share the output, that will
> > make it much easier for me to reproduce the issue and find a suitable
> > fix.
> > 
> > > do you have any idea if this might be fixed in the upcoming 2.36.3?
> > 
> > Most likely not. It might be fixed by chance due to shifting in the
> > sources which get included in each unified-source compilation unit,
> > tho -- but once I have a way to reproduce, I am confident it can be
> > solved.
> 
> I tried with the latest master branch (with 2.36.3) and extended the raspberrypi4_defconfig with graphics driver.
> 
> This is the defconfig:
>
> [...]

Thanks a lot for sharing your config, that was most helpful! I have been
able to reproduce the build issue and I am already working on a fix,
which will make it into the 2.36.4 release in some weeks. In the
meantime I will submit a fix to have the patch in Buildroot.

Cheers,
—Adrián