Re: Need help figuring out an e2fsprogs FTBFS on mips/mipsel

[Ted Ts'o <tytso@mit.edu>]

On Thu, Oct 06, 2011 at 06:39:47PM -0400, Ted Ts'o wrote:
> 
> 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....

So I've done a bit more digging, and bug #145432 gives a bit more
context.  It appears that the arcboot bootloader builds using
/usr/lib/libext2fs-nopic.a.  (delo doesn't appear to need it, though.)

What's not at all clear to me is who needs
/usr/lib/lib64ext2fs-nopic.a.  It was requested in #329074, but the
package that required lib64ext2fs-nopic.a was not specified in the bug
report.  I've cc'ed Thiemo Seufer, hoping that his e-mail address is
still valid, and that he can shed some light on this issue.

						- Ted