Hey all,
I have a odd situtation that im trying to work out the best way to handle. gcc on sparc needs glibc for sparc and sparc64 but it gets built as sparc. somehow i need to have sparc64 glibc in the buildroot only for gcc. even though the target is sparc.
Dennis
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Dennis Gilmore wrote:
Hey all,
I have a odd situtation that im trying to work out the best way to handle. gcc on sparc needs glibc for sparc and sparc64 but it gets built as sparc. somehow i need to have sparc64 glibc in the buildroot only for gcc. even though the target is sparc.
Dennis
I've started three replies to this and have bogged down every time. Sigh.
If I'm correct here, the problem is that you need both 32-bit and 64-bit glibc's in the same chroot to build gcc for a sparc. I looked on a x86_64 FC5 system and it has two glibc-2.4-8 packages, but if you list them both, one is the 64 bit version and the other is the 32-bit version. This implies to me that they were both "installed" as opposed to "updated". I can't really see an easy way to force mock/yum to do this, so I think the only way will be multiple invocations of mock and rpm. Something like:
$ mock -r fedora-devel-sparc-core init $ rpm --root /var/lib/mock/fedora-development-sparc-core/root \ -ihv glibc-2.4-8.sparc64.rpm $ mock -r fedora-devel-sparc-core --no-clean <path-to-gcc-srpm>
You can't install the 64-bit rpm while inside the chroot, because you're using the native RPM to do all RPM manipulations; hence the invocation of rpm.
It's ugly, but I'm not sure I see any other way to do what you're asking.
Clark
On Friday 18 August 2006 14:48, Clark Williams wrote:
If I'm correct here, the problem is that you need both 32-bit and 64-bit glibc's in the same chroot to build gcc for a sparc. I looked on a x86_64 FC5 system and it has two glibc-2.4-8 packages, but if you list them both, one is the 64 bit version and the other is the 32-bit version. This implies to me that they were both "installed" as opposed to "updated". I can't really see an easy way to force mock/yum to do this, so I think the only way will be multiple invocations of mock and rpm. Something like:
We handle this at Red Hat by having a file buildrequirement on a file that is provided by the 32bit glibc, as well as a buildrequirement on just glibc. This way no matter what arch you're on, you'll get the 32bit glibc. Now, at Red Hat we had to create a fake 'glibc32' package that is built x86_64 so that it is available in the x86_64 repo. Perhaps you can do the same for sparc?
On Friday 18 August 2006 14:05, Jesse Keating wrote:
On Friday 18 August 2006 14:48, Clark Williams wrote:
If I'm correct here, the problem is that you need both 32-bit and 64-bit glibc's in the same chroot to build gcc for a sparc. I looked on a x86_64 FC5 system and it has two glibc-2.4-8 packages, but if you list them both, one is the 64 bit version and the other is the 32-bit version. This implies to me that they were both "installed" as opposed to "updated". I can't really see an easy way to force mock/yum to do this, so I think the only way will be multiple invocations of mock and rpm. Something like:
We handle this at Red Hat by having a file buildrequirement on a file that is provided by the 32bit glibc, as well as a buildrequirement on just glibc. This way no matter what arch you're on, you'll get the 32bit glibc. Now, at Red Hat we had to create a fake 'glibc32' package that is built x86_64 so that it is available in the x86_64 repo. Perhaps you can do the same for sparc?
perhaps, but it needs to be the other way around. that is i need the 64 bit glibc in a 32bit chroot to build gcc. so i guess i need to build a glibc64 'fake' package gcc has a BuildRequires /lib64/libc.so.6 /usr/lib64/libc.so so its file based
I will work out what i need to do for the glibc64 package
Dennis
buildsys@lists.fedoraproject.org
-
Clark Williams -
Dennis Gilmore -
Jesse Keating