In order to get an in-house 32-bit ppc application running on CentOS 7, I've been rebuilding a number of SRPM's from 7.2.1511 on vault.centos.org. I'm down to three packages (glibc, gcc, and mesa) needing rebuilds to resolve "Protected multilib" errors when installing the Yum group that defines my application's "platform".
Each of these three is failing to rebuild in different ways, so I'm looking for some pointers as to what I'm doing wrong.
For glibc, the failure is that rpmbuild finds a number of installed but unpackaged files in the buildroot under /usr/lib/debug. I've tried setting a debuginfo-related macro in the mock.cfg, but I don't see that setting in the glibc mock.cfg on buildlogs.centos.org, so I think that might be a red herring.
For gcc, mock fails to set up the chroot because it can't find a package to provide /usr/lib64/libc.so (which is called out explicitly in a BuildRequires), even though the mock.cfg includes a repo containing glibc-devel.ppc64 and glibc.ppc64.
For mesa, the configure test for DRI3PROTO fails with dri3proto >= 1.0 not found. The F19 ppc backing repo I'm using has packages for Mesa 9.x, whereas 7.2.1511 is at Mesa 10.x. I'm guessing that some sort of manual intervention is needed to bootstrap across the major-version bump, but I haven't been able to work out the sequence.
I realize that ppc RPM's are in the cards, but I'm trying to do as much risk-reduction as I can due to an internal deadline. Any hints as to what I'm missing on these three packages would be greatly appreciated.
Thanks,
-Bryson ________________________________ This message (including any attachments) may contain confidential information intended for a specific individual and purpose. If you are not the intended recipient, you should delete this message and any attachments.
On Feb 16, 2016, at 11:54 PM, Bryson Lee Bryson.Lee@sslmda.com wrote:
For gcc, mock fails to set up the chroot because it can’t find a package to provide /usr/lib64/libc.so (which is called out explicitly in a BuildRequires), even though the mock.cfg includes a repo containing glibc-devel.ppc64 and glibc.ppc64.
To build multilib gcc.ppc, the trick I used was similar to Fedora’s glibc64 package
http://ppc.koji.fedoraproject.org/koji/packageinfo?packageID=9083
I basically took Fedora’s glibc64.spec and modified it using the binaries from
http://mirror.centos.org/altarch/7.2.1511/os/ppc64/Packages/glibc-2.17-105.e...
On Feb 16, 2016, at 11:54 PM, Bryson Lee Bryson.Lee@sslmda.com wrote:
For glibc, the failure is that rpmbuild finds a number of installed but unpackaged files in the buildroot under /usr/lib/debug. I’ve tried setting a debuginfo-related macro in the mock.cfg, but I don’t see that setting in the glibc mock.cfg on buildlogs.centos.org, so I think that might be a red herring.
I don’t recall any issues building glibc-2.17-105.el7.ppc.rpm once I had all the BuildRequires built. Sounds like you may not have the proper rpm macros established from one or all of these rpms:
centos-release-7-2.1511.el7.centos.2.9.altarch.src.rpm redhat-rpm-config-9.1.0-68.el7.centos.src.rpm rpm-4.11.3-17.el7.src.rpm
Make sure you aren’t building glibc with f19 copies of fedora-release, redhat-rpm-config and rpm.
On Feb 16, 2016, at 11:54 PM, Bryson Lee Bryson.Lee@sslmda.com wrote:
For mesa, the configure test for DRI3PROTO fails with dri3proto >= 1.0 not found. The F19 ppc backing repo I’m using has packages for Mesa 9.x, whereas 7.2.1511 is at Mesa 10.x. I’m guessing that some sort of manual intervention is needed to bootstrap across the major-version bump, but I haven’t been able to work out the sequence.
mesa is a more complicated endeavor as it has circular dependencies with mesa-libGL-devel and xorg-x11-server. But it sounds like you are pulling in Fedora 19 x11 library artifacts instead of building a clean CentOS x11 stack.
To rewind a bit, you basically use fedora 19 repos to build a minimal set of CentOS 7 ppc rpms. Then you turn off the Fedora 19 repos and attempt to build CentOS 7 ppc using only this minimal set of rpms. This leads to needing to unwind many painful circular dependencies but results in a much cleaner build with no Fedora library artifacts.
Here is the minimal set of CentOS 7.0.1406 ppc rpms I built with Fedora 19 backing
http://pastebin.centos.org/39881/
Everything else is built without Fedora 19 repo backing and the minimal set of CentOS rpms also gets rebuilt eventually.
On Feb 17, 2016, at 10:23 AM, James O'Connor wrote:
On Feb 16, 2016, at 11:54 PM, Bryson Lee Bryson.Lee@sslmda.com
wrote:
For mesa, the configure test for DRI3PROTO fails with dri3proto >= 1.0 not
found. The F19 ppc backing repo I’m using has packages for Mesa 9.x, whereas 7.2.1511 is at Mesa 10.x. I’m guessing that some sort of manual intervention is needed to bootstrap across the major-version bump, but I haven’t been able to work out the sequence.
mesa is a more complicated endeavor as it has circular dependencies with mesa-libGL-devel and xorg-x11-server. But it sounds like you are pulling in Fedora 19 x11 library artifacts instead of building a clean CentOS x11 stack.
To rewind a bit, you basically use fedora 19 repos to build a minimal set of CentOS 7 ppc rpms. Then you turn off the Fedora 19 repos and attempt to build CentOS 7 ppc using only this minimal set of rpms. This leads to needing to unwind many painful circular dependencies but results in a much cleaner build with no Fedora library artifacts.
Here is the minimal set of CentOS 7.0.1406 ppc rpms I built with Fedora 19 backing
Hi James,
Thanks for the clarifications!
Getting the RPM macro environment right fixed the glibc build, and the glibc64 technique got me over the first hurdle with gcc. I did have to bypass building the gcc-go compiler (actually libgo) due to compile errors that appear to be related to context handling. Unimportant for my use-case, but I'm not sure how one would ever build the unmodified gcc SRPM on ppc.
Rebuilding the x11 stack fixed the Mesa build.
There were some %file conflicts with manpages for certain ppc64 vs. ppc RPMS (nss, krb5, pam, pango, gtk2). I suspect that there's a "proper" way to deal with this in multilib environments; I took a field-expedient approach of separating the offending files out into a subpackage in the ppc build that then doesn't get pulled in to my yum install transaction.
Again, thanks much for all your help!
Regards,
-Bryson
________________________________ This message (including any attachments) may contain confidential information intended for a specific individual and purpose. If you are not the intended recipient, you should delete this message and any attachments.
On Feb 22, 2016, at 6:21 PM, Bryson Lee Bryson.Lee@sslmda.com wrote:
Hi James,
Thanks for the clarifications!
Getting the RPM macro environment right fixed the glibc build, and the glibc64 technique got me over the first hurdle with gcc. I did have to bypass building the gcc-go compiler (actually libgo) due to compile errors that appear to be related to context handling. Unimportant for my use-case, but I'm not sure how one would ever build the unmodified gcc SRPM on ppc.
Rebuilding the x11 stack fixed the Mesa build.
There were some %file conflicts with manpages for certain ppc64 vs. ppc RPMS (nss, krb5, pam, pango, gtk2). I suspect that there's a "proper" way to deal with this in multilib environments; I took a field-expedient approach of separating the offending files out into a subpackage in the ppc build that then doesn't get pulled in to my yum install transaction.
Again, thanks much for all your help!
Regards,
-Bryson
Glad some of the tips helped. I’ve built 3600+ ppc binary rpms and I’m just about ready take about 1800 of those (mostly libraries) and merge them into the ppc64 repos. Once we do a few days of testing to make sure we didn’t break ppc64, I’ll get the ppc rpms signed and pushed to http://mirror.centos.org/altarch/7.2.1511/os/ppc64/Packages/
gcc-go.ppc worked fine for me. I’m not sure where gcc.ppc and some of the ppc buildrequires will end up. Perhaps on buildlogs.centos.org or an altarch/7.2.1511/os/ppc tree that is useful for building but not installing/running.
-James
-
Bryson Lee -
James O'Connor