Bug 836155
Summary: | root fails to compile from source rpm | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | nvwarr |
Component: | root | Assignee: | Mattias Ellert <mattias.ellert> |
Status: | CLOSED WORKSFORME | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | low | Docs Contact: | |
Priority: | unspecified | ||
Version: | 17 | CC: | mattias.ellert, steve.traylen |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2012-06-28 14:35:22 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: |
Description
nvwarr
2012-06-28 09:00:19 UTC
I can not reproduce this on Fedora 17. If I try to rebuild the Fedora 17 root source rpm on an up-to-date (all updates applied) Fedora 17 installation today it succeeds. I have seen this compilation failure on Fedora 18, and the latest root source rpm in Fedora 18 has a patch for it. The problem I have seen in Fedora 18 is due to that Fedora 18 has a newer version of the glibc-headers that introduces an incompatibility with the root sources. I have reported this upstream: https://savannah.cern.ch/bugs/?95267 I need to follow up on that. They have put the ball back in my court... I have to see if I can make a patch that works with the new system headers without breaking with the old ones. Are you trying to compile the Fedora 17 root source rpm on Fedora 18 (rowhide), or have you for some reason installed a newer glibc-header package in your Fedora 17 than the one provided in the Fedora 17 repos? Standard Fedora 17 with all the updates and glibc-headers-2.15-37.fc17.x86_64. Is it perhaps a 64-bit issue? I have quitea few 32-bit libraries installed for compatability, so perhaps that is confusing the build? I don't think this is the same issue as the bug you show. In that case, there is a problem compiling bin/rmkdepend, but in my case, the build doesn't even try to build it and then complains that it doesn't exist. I didn't post the full output from the build, but the lines I posted were the first reference to rmkdepend apart from the sed to fix the manpages. For some reason, it is completely skipping the build of bin/rmkdepend. If I explicitly add a make bin/rmkdepend before the main make in the spec file, it builds bin/rmkdepend successfully, but then fails because include/TUnixSystem.h doesn't exist and if I fix that, it fails further along. i.e. when it creates the include directory, it is not copying all the headers into it. It's definitely a build problem, because it builds fine without the line rm -rf core/zip/src/[a-z]* core/zip/inc/[a-z]* |