Bug 1771031 - graph-tool 2.43 does not build on ppc64le
Summary: graph-tool 2.43 does not build on ppc64le
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: python-graph-tool
Version: 36
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Ben Beasley
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 1649936 CGAL_FTBFS_in_F36
Blocks: PPCTracker
TreeView+ depends on / blocked
 
Reported: 2019-11-11 18:31 UTC by Ankur Sinha (FranciscoD)
Modified: 2022-02-09 15:38 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-02-09 15:38:33 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
build log for failed ppc64le build (490.68 KB, text/plain)
2019-11-11 18:31 UTC, Ankur Sinha (FranciscoD)
no flags Details
Detailed logs from from failing configure script (178.75 KB, text/plain)
2022-02-01 21:27 UTC, Ben Beasley
no flags Details

Description Ankur Sinha (FranciscoD) 2019-11-11 18:31:27 UTC
Created attachment 1634967 [details]
build log for failed ppc64le build

graph-tool does not currently build on ppc64le.

Complete build log attached. Help appreciated.

Comment 1 Dan Horák 2019-11-12 13:14:48 UTC
Looks like it failed due out-of-memory on the builder. "g++: fatal error: Killed signal terminated program cc1plus" is the symptom. Workarounds are to reduce parallelism or debuginfo verbosity. Fedora infra is also reviewing the builder VM setup to have good ration between memory size and number of virtual CPUs.

Comment 2 Ankur Sinha (FranciscoD) 2019-11-12 14:43:25 UTC
Make was running with -j1 here, so a serial build. :(

Comment 3 Ben Cotton 2020-11-03 15:47:54 UTC
This message is a reminder that Fedora 31 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '31'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 31 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 4 Ben Cotton 2021-02-09 15:13:20 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 34 development cycle.
Changing version to 34.

Comment 5 Ben Cotton 2021-08-10 12:46:48 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 35 development cycle.
Changing version to 35.

Comment 6 Ben Beasley 2021-09-09 16:09:09 UTC
Updating this bug to reflect current status. I worked around the resource exhaustion following

> note: variable tracking size limit exceeded with '-fvar-tracking-assignments', retrying without

by reducing the level of debugging symbols on architectures that were hitting resource limits:

> %ifarch armv7hl ppc64le s390x
> %global optflags %(echo %{optflags} | sed 's/-g /-g1 /')
> %endif

Now the problem looks like:

>   /usr/include/boost/math/tools/promotion.hpp:138:10:
>   error: static assertion failed:
>   Sorry, but this platform does not have sufficient long double support for
>   the special functions to be reliably implemented.

That looks pretty conclusive, so I’m closing this issue as CANTFIX. (It will still satisfy the ExcludeArch tracking requirement by blocking PPCTracker.)

Comment 7 Dan Horák 2021-09-10 16:25:16 UTC
I believe it's waiting on https://fedoraproject.org/wiki/Changes/PPC64LE_Float128_Transition to be implemented.

Comment 8 Ben Beasley 2021-09-10 17:59:31 UTC
(In reply to Dan Horák from comment #7)
> I believe it's waiting on
> https://fedoraproject.org/wiki/Changes/PPC64LE_Float128_Transition to be
> implemented.

Thanks! I wasn’t aware of that change proposal.

I’m reopening this bug, and blocking it on the change tracker bug, since that is a likely fix.

Unfortunately, it looks like the change proposal was deferred, and it’s not clear when or if it will be resubmitted.

Comment 9 Dan Horák 2022-01-26 20:11:41 UTC
and the change was implemented for F-36, please give it a try

Comment 10 Ben Beasley 2022-01-27 20:40:29 UTC
Thanks. I’m away from a suitable computer at the moment, but I’ll try it in the next week or two—or perhaps Ankur will have a chance.

Comment 11 Ben Beasley 2022-02-01 20:38:36 UTC
I gave it another try[1], and found that the configure script could not find CGAL on ppc64le *only*. I know that CGAL became header-only in 5.4.0, but everything is working fine on x86_64, aarch64, and s390x. I’ll have to try to figure out what is different on PowerPC.

checking for __gmpz_init in -lgmp... yes
checking for __gmpz_init in -lgmp... (cached) yes
checking whether CGAL is available in /usr... checking whether CGAL is available in /usr... no
checking whether CGAL is available in /usr/local... checking whether CGAL is available in /usr/local... no
checking whether CGAL is available in /opt... checking whether CGAL is available in /opt... no
checking whether CGAL is available in /opt/local... checking whether CGAL is available in /opt/local... no
configure: error: CGAL library not found.

[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=82254634

Comment 12 Dan Horák 2022-02-01 20:52:17 UTC
I guess it's because you can't "include" the CGAL headers on ppc64le, they will throw an error. See the links from bug 2045152 for details.

Comment 13 Dan Horák 2022-02-01 20:53:21 UTC
The most details are in https://github.com/boostorg/multiprecision/issues/419

Comment 14 Ben Beasley 2022-02-01 21:02:49 UTC
Thanks! That makes sense. I’ll keep an eye on the upstream bugs (CGAL/Boost/GCC). I’ll also do an emulated ppc64le mock-build and dig through the config.log to verify that the messages therein are in fact consistent with bug 2045152.

Comment 15 Ben Beasley 2022-02-01 21:03:43 UTC
Changing the version to Rawhide, as this won’t be fixed in F35.

Comment 16 Ben Beasley 2022-02-01 21:27:11 UTC
Created attachment 1858474 [details]
Detailed logs from from failing configure script

It’s definitely the CGAL/Boost/GCC issue. From config.log:

> configure:22319: g++ -o conftest -fopenmp -g -O2 -fexceptions -g1 -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  -I/usr/include -pthread -I/usr/include -Wl,-z,relro -Wl,--as-needed  -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -Wl,--build-id=sha1 -Wl,-dT,/builddir/build/BUILD/graph-tool-2.43/.package_note-python-graph-tool-2.43-11.fc36.ppc64le.ld -L/usr/lib64  conftest.cpp -lgmp -lgmp  >&5
> In file included from /usr/lib/gcc/ppc64le-redhat-linux/12/include/immintrin.h:29,
>                  from /usr/include/boost/multiprecision/cpp_int/intel_intrinsics.hpp:68,
>                  from /usr/include/boost/multiprecision/cpp_int/add_unsigned.hpp:10,
>                  from /usr/include/boost/multiprecision/cpp_int/add.hpp:12,
>                  from /usr/include/boost/multiprecision/cpp_int.hpp:2286,
>                  from /usr/include/CGAL/boost_mp.h:33,
>                  from /usr/include/CGAL/Number_types/internal/Exact_type_selector.h:27,
>                  from /usr/include/CGAL/Exact_kernel_selector.h:26,
>                  from /usr/include/CGAL/Filtered_kernel.h:22,
>                  from /usr/include/CGAL/Exact_predicates_inexact_constructions_kernel.h:21,
>                  from conftest.cpp:58:
> /usr/lib/gcc/ppc64le-redhat-linux/12/include/mmintrin.h:52:2: error: #error "Please read comment above.  Use -DNO_WARN_X86_INTRINSICS to disable this error."
>    52 | #error "Please read comment above.  Use -DNO_WARN_X86_INTRINSICS to disable this error."
>       |  ^~~~~
> In file included from /usr/lib/gcc/ppc64le-redhat-linux/12/include/immintrin.h:31:
> /usr/lib/gcc/ppc64le-redhat-linux/12/include/xmmintrin.h:54:2: error: #error "Please read comment above.  Use -DNO_WARN_X86_INTRINSICS to disable this error."
>    54 | #error "Please read comment above.  Use -DNO_WARN_X86_INTRINSICS to disable this error."
>       |  ^~~~~
> […]

Comment 17 Ben Beasley 2022-02-04 12:46:51 UTC
I just merged the PR to re-enable ppc64le[1] and kicked off a build[2]. That should close this bug when it finishes.

Thank you, Dan, for helping debug this.

[1] https://src.fedoraproject.org/rpms/python-graph-tool/pull-request/4
[2] https://koji.fedoraproject.org/koji/taskinfo?taskID=82371452

Comment 18 Ben Cotton 2022-02-08 20:16:17 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 36 development cycle.
Changing version to 36.

Comment 19 Ben Beasley 2022-02-09 15:38:33 UTC
Not sure why this didn’t auto-close, but it’s fixed now, for F36 and later.


Note You need to log in before you can comment on or make changes to this bug.