On 2021-11-23 02:12, Fabio Valentini wrote:
On Tue, Nov 23, 2021 at 10:00 AM Luya Tshimbalanga
<luya@xxxxxxxxxxxxxxxxx> wrote:
On 2021-11-22 01:24, Dan Horák wrote:
On Mon, 22 Nov 2021 01:12:56 -0800
Luya Tshimbalanga <luya@xxxxxxxxxxxxxxxxx> wrote:
Hello team,
Academic Software Foundation released OpenVDB 9.0.0 with support of
NanoVDB [1] which is useful for Blender 3D [2]. Scratch build resulted a
failure on arm7vh architectures related to exhausted virtual memory [3].
Suggested workaround is to decrease the debugging verbose noise in the
spec file with no success. Extract below:
no success, because it had no effect on the flags used in the build as
can be verified in the build.log. Perhaps cmake needs a different
treatment for the compiler flags ...
Dan
Looking at cmake documentation, the command in the spec file seems like:
%cmake_build -j4
But '-j4' failed to get taken account.
That's because the "-j4" flag only works for running plain "cmake",
and not for the "%cmake_build" macro.
If you want to actually limit build parallelism, you should set
"%global _smp_mflags -j4".
Or, if you only need to have this work on rawhide, I think you could
use the new "%constrain_build" macro:
https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/rawhide/f/macros.build-constraints
Thank you. The change is only specific to armv7hl architecture whose
build system ran out of virtual memory. After applying the change like
%ifarch %{arm}
%global _smp_mflags -j4
%endif
It seems the virtual memory issue remains. For the time being, I will
temporarily exclude armv7 architecture.
As for %cmake_build not honoring -g1 flags passed in via the
environment, I'd check if any of the CMakeLists.txt files (or the
%cmake_build macro, for that matter) override CfooFLAGS to always add
"-g" regardless of the environment. I had that happen with various
CMake-based projects I used to work with, and fixed that issue
upstream.
Sadly, I am unable to find any CMakeLists.txt with that "-g" flag. Since
arm architecture is the only affected build, I will exclude it for the
time being until a better solution comes.
--
Luya Tshimbalanga
Fedora Design Team
Fedora Design Suite maintainer
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
