Re: Need help figuring out an e2fsprogs FTBFS on mips/mipsel
Hi.
I'm still an newbie in mips-land, but try to write how I understood it
up to now.
* Ted Ts'o (tytso@mit.edu) [111007 00:40]:
> On Thu, Oct 06, 2011 at 10:38:09PM +0200, Andreas Barth wrote:
> > Looks to me like a missing build-dependency on gcc-multilib.
> > Adding this one resolves the issue (and the package is installed on
> > gabrielli already, that's why it doesn't happen there).
>
> Oh, I see. We don't actually try to build a library for the
> non-default architecture on any other architecture *other* than mips,
> where we build both a 32-bit and 64-bit static library. So this is
> why the problem doesn't show up on other architectures. I'm kinda
> curious why this never was a problem for older (e2fsprogs 1.41.x)
> packages, but whatever.
>
> So what is the 64-bit story on MIPS, anyway? On other architectrues,
> we have a separate architecture for 32-bit vs. 64-bit (i.e., i386 vs
> x86_64). But on mips, we don't have that; instead we seem to have
> big-endian versus little-endian.
On mips*, the default situation is the similar to any machine running
an amd64-kernel and i386 userland, 64bit kernel and 32bit userland and
the ability to execute 64bit code (e.g. in a chroot). With the
difference that as of today there is no 64bit userland. (However,
mips* has not only two abis as such an x86-machine, but three - o32,
n32, n64, see http://www.linux-mips.org/wiki/MIPSABIHistory )
(The endianess is totally unrelated. Most machines are only one
endianess, except some development boxes.)
> So is it normal for mips packages to ship both 32-bit and 64-bit
> libraries in the same package?
It's normal to not ship 64bit libraries.
However, in the case of e2fsprogs the 64bit libraries seem to be
relevant for some boot loader. Ideally, with multiarch, we could
compile the few relevant packages on 64bit mips, and not special case
things like here. But we don't have 64bit mips yet.
> And the MIPS specific hackery that we have in the e2fsprogs (a) is
> only for libext2fs.a, and not for any of the other libraries that I'd
> expect would be needed for any ext2/3/4 program (i.e., libe2p,
> libcom_err, etc.)
As far as I understood it's only for reading ext2 filesystems to read
the kernel / initrd within the boot loader.
> Also (b) it's using a nonstandard location:
> /usr/lib/libext2fs-nopic.a and /usr/lib/lib64ext2fs-nopic.a. So it's
> not even consistent with the multiarch proposal.
It's way prior to multiarch.
I hope someone else can answer "do we need it" - however, after
reading the bug report, I would tend to answer with "yes" unless
someone provides a reason why not.
Andi
Reply to: