On Fri, 2008-04-18 at 05:19 +0200, Ralf Corsepius wrote:
> On Thu, 2008-04-17 at 13:27 -0500, Rex Dieter wrote:
> > Sérgio Durigan Júnior wrote:
> >
> > > Well, what happens is that in some archs (specifically PowerPC in our
> > > case) it's very common to have a biarch environment (i.e., 64-bit kernel
> > > and mixed 32/64-bit userspace), so it's not a strange thing to have both
> > > versions of some software installed in the system.
> >
> > Right. If there are 32/64 packages available, and they don't properly
> > install/run, then that's generally considered a bug (that should be fixed).
>
> Here is one:
>
> # rpm -q --qf "%{name}.%{arch}\n" -f /lib/libgcc_s.so.1
> libgcc.i386
>
> # rpm -q --qf "%{name}.%{arch}\n" -f \
> /usr/lib/gcc/x86_64-redhat-linux/4.3.0/32/libgcc_s.so
> gcc.x86_64
>
> # ls -l /usr/lib/gcc/x86_64-redhat-linux/4.3.0/32/libgcc_s.so
> /usr/lib/gcc/x86_64-redhat-linux/4.3.0/32/libgcc_s.so
> -> /lib/libgcc_s.so.1
>
> i.e. an x86_64 package depending on an i386 package.
>
>
> Now try to install /lib/libgcc_s.so.1 in an x86_64 mock chroot.
>
> I am trying to package a package which needs to build and run some bits
> "-m32 compiled on x86_64". Works in a normal (multilib'ed x86_64)
> environment, but I haven't managed to get this working in mock.
>
>
try using yum 3.2.14 from rawhide with mock and remove the silly exclude
that's in mock currently for x86_64 builds.
I know mdomsch and jkeating have tested it and had good success with
multilib_policy=best
-sv
--
Fedora-packaging mailing list
Fedora-packaging@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-packaging
