On Sun, 11 Aug 2019 17:50:17 +0200, Chris Murphy wrote:
I don't follow. You're saying RelWithDebInfo is never suitable for a local build?
Most of the time. What is your use case for it?
isn't relevant to getting a successful build.
With powerful enough machine everything is possible. Just be aware RelWithDebInfo is the most resource demanding option compared to Release and Debug and at the same time it is the least useful one for local builds.
In file included from Source/JavaScriptCore/config.h:32, from Source/JavaScriptCore/llint/LLIntSettingsExtractor.cpp:26: Source/JavaScriptCore/runtime/JSExportMacros.h:32:10: fatal error: wtf/ExportMacros.h: No such file or directory
You are reinventing the wheel Fedora packager has already done for this package. I guess you are missing some dependency. If you have a problem stick to the proven build (unless it is temporarily FTBFS which this package is not now). I think Fedora recommends mock for such rebuild but I find mock inconvenient for local development so I use (I have some scripts for that): dnf download --source webkit2gtk3 mkdir webkit2gtk3-2.24.3-1.fc30.src cd webkit2gtk3-2.24.3-1.fc30.src rpm2cpio ../webkit2gtk3-2.24.3-1.fc30.src.rpm|cpio -id function rpmbuildlocal { time MAKEFLAGS= rpmbuild --define "_topdir $PWD" --define "_builddir $PWD" --define "_rpmdir $PWD" --define "_sourcedir $PWD" --define "_specdir $PWD" --define "_srcrpmdir $PWD" --define "_build_name_fmt %%{NAME}-%%{VERSION}-%%{RELEASE}.%%{ARCH}.rpm" "$@"; rmdir &>/dev/null BUILDROOT; } # Is the .src.rpm rebuild still needed? https://bugzilla.redhat.com/show_bug.cgi?id=1210276 rpmbuildlocal -bs *.spec sudo dnf builddep webkit2gtk3-2.24.3-1.fc30.src.rpm rm webkit2gtk3-2.24.3-1.fc30.src.rpm rpmbuildlocal -bc webkit2gtk3.spec 2>&1|tee log # or -bb or what do you want. It has built fine for me here now.
Let's take another argument. If the user manually specifies 'ninja -j 64' on this same system, is that sabotage?
For untrusted users Linux has given up for that, it is too big can of worms. Use virtual machine (KVM) with specified resources (memory size). Nowadays it should be also possible with less overhead by using Docker containers.
If you mean some local builds of your own causing runaway then (1) Turn off swap as RAM is cheap enough today. If something really runs out of the RAM it gets killed by kernel OOM. (2) Have the swap on NVMe, it from my experience does not kill the machine. (3) Use some reasonable ulimits in your ~/.bash_profile. (4) When the machine is really unresponsible login there from a different box and kill the culprits. From my own experience the machine is still able to accept new SSH connection, despite a bit slowly. But yes, I agree this problem has AFAIK no perfect solution.
Jan