On Thu, 2008-04-17 at 23:33 -0400, seth vidal wrote:
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.
OK, this will likely resolve the
"mock" part of this issue (yet
untested), but leaves other parts unclear:
Which rpm "arch" and which package does the
/usr/lib/gcc/x86_64-redhat-linux/4.3.0/32/libgcc_s.so
-> /lib/libgcc_s.so.1 symlink belong to?
ATM, it is part of gcc.x86_86 and is a dangling symlink in "pure
basearch" installs.
Should it (or even the whole m32 subdir) be part of an *.i386 package?
Or, conversely should /lib/libgcc_s.so.1 (clearly i386'ed) be part of a
"multilib'ed" gcc.x86_64 package or libgcc.x86_64 package?
I don't know.
Ralf