Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1242873
Summary: | php 5.6.1[01] is FTBFS on aarch64 | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Peter Robinson <pbrobinson> | ||||
Component: | postgresql | Assignee: | Pavel Raiskup <praiskup> | ||||
Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | high | Docs Contact: | |||||
Priority: | high | ||||||
Version: | 23 | CC: | dan, devrim, fedora, hhorak, jmlich, jorton, jstanek, praiskup, tgl | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | aarch64 | ||||||
OS: | Unspecified | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2015-07-16 07:44:44 UTC | Type: | Bug | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Bug Depends On: | |||||||
Bug Blocks: | 922257 | ||||||
Attachments: |
|
Description
Peter Robinson
2015-07-14 10:06:31 UTC
Pavel AFAICS, you are doing the multilib dance in postgresql.spec for aarch64 but the pg_config.h doesn't actually have a #if section for that arch? I may be missing something but it fits the symptom, effectively pg_config.h appears empty. Shouldn't need a multilib dance on aarch64, we don't support it. Also weird in that this use to work, wonder what changed recently Yes, the multilib hack in postgresql.spec is broken. Spec file classifies aarch64 as multilib but it is not correct. (In reply to Peter Robinson from comment #2) > Shouldn't need a multilib dance on aarch64, we don't support it. Also weird > in that this use to work, wonder what changed recently It is quite recent commit, Peter. Could this be relevant? http://pkgs.fedoraproject.org/cgit/postgresql.git/commit/?id=e6acde1a903c7360e quite possibly, was there a reason it was added, I only see the older bug referenced. ppc64le or armv7hl aren't referenced and they're not multilib either. Technically nor is ppc64* either any more at least for Fedora since we dropped ppc32 with Fedora 20 (although it's probably worth leaving it there) (In reply to Peter Robinson from comment #4) > quite possibly, was there a reason it was added, I'm not aware of any reason. I'll revert that part of commit related to arch classification -- it seems to be clear bug. > I only see the older bug > referenced. ppc64le or armv7hl aren't referenced and they're not multilib > either. Technically nor is ppc64* either any more at least for Fedora since > we dropped ppc32 with Fedora 20 (although it's probably worth leaving it > there) Well IIUC, ppc64p7 is distinct (incompatible) architecture from ppc64 and as such its unlikely it will have 32bit counterpart -- I'll revert that also. I also don't think removing 'ppc' vs 'ppc64' from multilib hack makes much sense as it is not broken and it might still be useful to someone.
> Well IIUC, ppc64p7 is distinct (incompatible) architecture from ppc64 and as
No, that's incorrect, it's completely compatible with ppc64 (Power 64 bit Big Endian) but just with optimisations for the Power7 architecture. There's around 30-40 packages such as DBs that have a large perf improvement
Thanks for the info. Then better fix than "just revert" is needed probably, if we do want to keep multilib support for that. Is macro __ppc64__ defined on ppc64v7? Just 2c: it would be nice to have an #else/#error in pg_config.h so the failure case was more obvious, most other multilib wrappers do that. (In reply to Pavel Raiskup from comment #7) > Thanks for the info. Then better fix than "just revert" is needed probably, > if we do want to keep multilib support for that. Is macro __ppc64__ defined > on ppc64v7? I think we can probably leave the ppc64* stuff as is and just drop the aarch64 bits. (In reply to Peter Robinson from comment #9) > I think we can probably leave the ppc64* stuff as is and just drop the > aarch64 bits. IMO only if __ppc64__ is also defined on ppc64v7, otherwise the pg_config.h is not yet ready for this arch. (In reply to Pavel Raiskup from comment #10) > (In reply to Peter Robinson from comment #9) > > I think we can probably leave the ppc64* stuff as is and just drop the > > aarch64 bits. > > IMO only if __ppc64__ is also defined on ppc64v7, otherwise the pg_config.h > is not yet ready for this arch. Yes, it should be, the difference is basically just the CFLAGS defined. Created attachment 1051810 [details]
Possible fix.
Peter, does the patch attached look right then?
(In reply to Pavel Raiskup from comment #12) > Possible fix. Hm, won't that lead to the ppc64p7 and ppc64 builds both creating pg_config_ppc64.h? It might be okay since I think the files would have identical contents, but that seems like a fragile assumption. Generally ppc64 and ppc64p7 are like were i386 and i686 used in Fedora in the past. The compiler should define just __powerpc64__ on both. The difference is set on the rpm level (by using different -mcpu/-mtune flags). (In reply to Tom Lane from comment #13) > (In reply to Pavel Raiskup from comment #12) > > Possible fix. > > Hm, won't that lead to the ppc64p7 and ppc64 builds both creating > pg_config_ppc64.h? Thanks for looking at it, that was expected change. Because we do not want to have pg_config_ppc64v7.h -> because we do not have __ppc64v7__ macro to add new "#ifdef" fork into pg_config.h (or if we do, it probably does not make much sense to add the fork). Currently, if postgresql.spec was actually ever built on ppc64v7 (and aarch64), postgresql-devel has broken pg_config.h. So do we have agreement here on the fix? Can we get it pushed to f23/f24 please? This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle. Changing version to '23'. (As we did not run this process for some time, it could affect also pre-Fedora 23 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23 Update? Sorry for the delay. Yep, I pushed the commit above - however there is still one FTBFS bug #1242817 which needs to be fixed before submit a build. (In reply to Peter Robinson from comment #16) > So do we have agreement here on the fix? Can we get it pushed to f23/f24 > please? http://koji.fedoraproject.org/koji/buildinfo?buildID=669462 http://koji.fedoraproject.org/koji/buildinfo?buildID=669461 thanks, building now Confirmed fixed building of php. Thanks |