Re: Need help figuring out an e2fsprogs FTBFS on mips/mipsel
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.
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.
> 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....
- Ted
Reply to: