Re: Need help figuring out an e2fsprogs FTBFS on mips/mipsel
On Thu, Oct 06, 2011 at 06:39:47PM -0400, Ted Ts'o wrote:
> 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.
My guess is that it is due to the recent multiarch changes, which moved
the kernel headers, and made them accessible only when some other
packages are installed.
> 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.
>
> So is it normal for mips packages to ship both 32-bit and 64-bit
> libraries in the same package?
>
> 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.) 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.
All of that comes from bug#329074. On mips/mipsel, the userland is
usually 32 bits, while kernel is usually 64-bit (like on sparc, s390 for
example). This also means that the bootloaders have to be 64 bits, and
as they need to read ext2 filesystem, they use libext2fs which has to be
in 64 bits too.
> > The other option would be to remove the mips-special-code - but please
> > don't ask me why this was added.
> >
> > Looks to me like related to #329074. I'll let the answer to that to
> > someone more knowledgeable.
>
> So could someone in the debian-mips tell me what would happen if I
> just simply removed all of the specialized code to build and install
> /usr/lib/lib64ext2fs-nopic.a and /usr/lib/libext2fs-nopic.a?
>
> It close to doubles the time needed to build e2fsprogs on the MIPS
> architecture, causes MIPS-specific bugs, and the value it adds is very
> unclear to me....
>
I have looked at arcboot (the reason for bug#329074), sibyl and colo,
none of them use lib64ext2fs-nopic.a. They use libext2fs-nopic.a
though. That said given the purpose of this library is to be linked
statically, it's difficult to track exactly where it is used.
In conclusion it *seems* that lib64ext2fs-nopic.a can be dropped (but
not libext2fs-nopic.a). In anycase it's possible to make the package
build as before using "gcc-multilib [mips mipsel]" as a
build-dependency.
Aurelien
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurelien@aurel32.net http://www.aurel32.net
Reply to: