On Fri, 2 Dec 2022 09:01:43 +0100
Dan Horák <[email protected]> wrote:
> On Thu, 1 Dec 2022 17:51:08 -0800
> Luya Tshimbalanga <[email protected]> wrote:
>
> > Hello team,
> >
> > openvdb only failed on ppc64 architecture due to this error:
> >
> > --
> >
> > [ 75%] Building CXX object
> > openvdb/openvdb/CMakeFiles/openvdb_static.dir/instantiations/Composite.cc.o
> > cd /builddir/build/BUILD/openvdb-10.0.1/redhat-linux-build/openvdb/openvdb
> > && /usr/bin/g++ -DBOOST_IOSTREAMS_DYN_LINK -DBOOST_IOSTREAMS_NO_LIB
> > -DOPENVDB_PRIVATE -DOPENVDB_STATICLIB -DOPENVDB_USE_DELAYED_LOADING
> > -I/builddir/build/BUILD/openvdb-10.0.1/openvdb/openvdb/..
> > -I/builddir/build/BUILD/openvdb-10.0.1/redhat-linux-build/openvdb/openvdb
> > -I/builddir/build/BUILD/openvdb-10.0.1/redhat-linux-build/openvdb/openvdb/openvdb
> > -I/builddir/build/BUILD/openvdb-10.0.1/openvdb/openvdb/. -O2 -flto=auto
> > -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall
> > -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
> > -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
> > -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mcpu=power8
> > -mtune=power8 -fasynchronous-unwind-tables -fstack-clash-protection
> > -Wl,--as-needed -DNDEBUG -std=c++17 -MD -MT
> > openvdb/openvdb/CMakeFiles/openvdb_static.dir/instantiations/Composite.cc.o
> > -MF CMakeFiles/openvdb
_s
> tatic.dir/instantiations/Composite.cc.o.d -o
> CMakeFiles/openvdb_static.dir/instantiations/Composite.cc.o -c
> /builddir/build/BUILD/openvdb-10.0.1/redhat-linux-build/openvdb/openvdb/instantiations/Composite.cc
> > g++: fatal error: Killed signal terminated program cc1plus
> > compilation terminated.
> > gmake[2]: ***
> > [openvdb/openvdb/CMakeFiles/openvdb_shared.dir/build.make:625:
> > openvdb/openvdb/CMakeFiles/openvdb_shared.dir/instantiations/GridOperators.cc.o]
> > Error 1
> > gmake[2]: *** Deleting file
> > 'openvdb/openvdb/CMakeFiles/openvdb_shared.dir/instantiations/GridOperators.cc.o'
> > gmake[2]: *** Waiting for unfinished jobs....
> > --
> >
> > Could someone investigate the issue for that architecture? We may
> > possibly temporarily disable that support until the problem gets
> > resolved. Included is the attached spec yet committed.
>
> I will take a closer look, but it looks to me like "OOM killer in
> action", thus reducing build parallelism might help.
I can confirm it's "OOM" indeed, I have reproduced it locally. So far I
can say 6GB per g++ process still isn't sufficient, trying to find the
required amount ...
Dan
_______________________________________________
devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
