Re: WebKitGTK-2.52.5

On 8/19/26 10:10 PM, Pierre Labastie ([email protected] via blfs-dev Mailing 
List) wrote:
> On Wed, 2026-08-19 at 20:56 -0500, Bruce Dubbs wrote:
>> On 8/19/26 6:51 PM, Bruce Dubbs wrote:
>>> On 8/19/26 5:46 PM, Zeckma ([email protected] via blfs-dev
>>> Mailing List) wrote:
>>>> On 8/19/26 15:58, Bruce Dubbs ([email protected] via blfs-dev
>>>> Mailing List) wrote:
>>>>   > I had a bit of a problem with building WebKitGTK-2.52.5 on a
>>>> 13.1
>>>>   > system. I'm using a system with 28 cores.  When I tried to
>>>> build
>>>>   > WebKitGTK-2.52.5 using all 28 cores, it failed to build.  The
>>>>   > message was something about a file that was not complete.  I
>>>>   > tried twice and it failed at the same point.  I then tried at
>>>> -j8
>>>>   > and the build was successful.
>>>>
>>>> I suspect that this is a result of incomplete dependency
>>>> information.
>>>> I've run into this with samurai, a reimplementation of the Ninja
>>>> build system, which runs into this issue a lot. But it isn't
>>>> really
>>>> the fault of samurai.
>>>>
>>>> -j1 or a small amount of threads will conveniently get around the
>>>> issue of missing dependency information, but if a large or
>>>> larger amount of threads are used, a rule or target simply won't
>>>> wait for another to complete, and bails. With dependency
>>>> information,
>>>> the rule will then wait for the dependent rule/target to complete
>>>> before running.
>>>>
>>>> With how large WebKitGTK is, I imagine this is such a case.
>>>> Usually, this seems to happen more with Meson, and I haven't seen
>>>> a CMake case yet. But typically this is very fixable if you know
>>>> what depedency information is missing and what needs it.
>>>>
>>>> Thus, the solution would be to fix the code. Another may be to
>>>> use
>>>> Make instead of Ninja and see if that helps, but Ninja due to its
>>>> methodology happens to avoid most stuff like this except for lots
>>>> of targets that big projects like WebKitGTK need. So if Make
>>>> doesn't
>>>> bear fruit or it's really inconsistent, either an admon (note,
>>>> important, etc.) or fixing the build system would be my two
>>>> recommendations.
>>>>
>>>> What was your build error? May give a good clue as to what the
>>>> target
>>>> is that is missing the dependency information...
>>>
>>> Right, I figured it is a dependency issue with a generated file.
>>>
>>> I've overwritten the log.  I suppose I can run it again without the
>>> install. I'm
>>> still trying to update to Qt-6.11.2 so it will be a while until I
>>> can do that.
>>>
>>> BYW, I noticed that qt6 patch has been incorporated into 6.11.2,
>>> but qtopcua still
>>> breaks.
>>
>> I ran it again and saved the output.
>>
>> [8461/9424] Building CXX object
>> Source/WebCore/CMakeFiles/WebCore.dir/__/__/WebCore/DerivedSources/un
>> ified-sources/UnifiedSource-be65d27a-7.cpp.o
>> FAILED: [code=1]
>> Source/WebCore/CMakeFiles/WebCore.dir/__/__/WebCore/DerivedSources/un
>> ified-sources/UnifiedSource-be65d27a-7.cpp.o
>>
>>
>> That was on line 57222 of the output.  Around line 57621 is the
>> message:
>>
>> Assembler messages:
>> {standard input}:93901: Warning: end of file not at end of a line;
>> newline inserted
>> c++: fatal error: Killed signal terminated program cc1plus
>> compilation terminated.
>>
>> I was monitoring CPU and memory while it was building.  I saw 98%
>> memory usage (I
>> have 64G ram) and load values up to 28.  It's possible I ran out of
>> memory, but I do
>> have 8G swap.
>>
> 
> I'm almost sure it is an OOM problem. On a 16GB virtual machine, I need
> to pass -j3. -j4 and higher fails. Those "UnifiedSource" files may need
> more than 3GB for compilation. So at -j4, I may need ore than 12GB,
> which together with memory used by the system makes it more than 16GB.
> 
> I think with 64GB, allowing around 4GB for the system, you shouldn't
> run more than 20 threads, or maybe a little less. Note that swapping
> will slow down the system a lot, don't rely on it!
> 
> We already say in "notes on building software":
> ---
> Some compilations with g++ may consume up to 2.5 GB
> of memory, so to be safe, you should restrict the number of jobs
> to (Total Memory in GB)/2.5, at least for big packages such as LLVM,
> WebKitGtk, QtWebEngine, or libreoffice.
> ---
> I think now 2.5 should be replaced with 3. Also, I've never seen a
> problem in libreoffice or llvm...

Yes, I think you are right.  We do have a paragraph in an 'Important' note in Webkit. 
  My problem is that I haven't run into it before on a system with 64G of RAM.

   -- Bruce

-- 
http://lists.linuxfromscratch.org/sympa/info/blfs-dev
Unsubscribe: See the above information page