It looks like that it is not data from file that is being compared here, but data from an internal buffer previously stored in host byte order.

To expand on this, function `check_bam_aux_get` returns a pointer to auxiliary data which is stored in `aln->data` (`aln` is a variable of type `bam1_t`). This structure has previously been filled with data from input file in function `sam_parse1` during reading of input file.

This particular 4 byte integer value is copied to the internal buffer in sam.c:830

```
830       kputc_('B', &str); kputc_(type, &str); kputsn_(&n, 4, &str);
```

`kputsn_` is defined as (htslib/kstring.h:178):

```
static inline int kputsn_(const void *p, int l, kstring_t *s)
{
        if (s->l + l > s->m) {
                char *tmp;
                s->m = s->l + l;
                kroundup32(s->m);
                if ((tmp = (char*)realloc(s->s, s->m)))
                        s->s = tmp;
                else
                        return EOF;
        }
        memcpy(s->s + s->l, p, l);
        s->l += l;
        return l;
}
```

Four bytes of integer variable `n` are copied to `(str->s+str->l)` which is the address inside the internal buffer. The value is stored in host byte order, which is big endian in case of big endian mips.

Finally, at the end of `sam_parse1`, `b->data` is assigned to be `str->s`.

```
842         b->data = (uint8_t*)str.s; b->l_data = str.l; b->m_data = str.m;
```

Also, I came upon a comment in function `sam_parse1` placed before the parsing of aux data (sam.c:778) that states:

```
// Note that (like the bam1_core_t fields) this aux data in b->data is
 // stored in host endianness; so there is no byte swapping needed here.
```

As far as I can see, this practice is also followed for other formats, e.g. when data is read from input BAM files and/or written to output BAM files, function `swap_data` (sam.c:268) is used for converting multibyte values from little endian to big endian format and vice versa, depending on the operation. Again, aux data is kept in host byte order.

Taking this into account, the change from `"Bc\3\0\0\0\xfe\x00\x02"` to `"Bc\0\0\0\3\xfe\x00\x02"` reflects the difference in data endianness (depending on the host), not a change in the input file itself.

As I am not an expert on the subject, I could be wrong, so any suggestions on how to correctly support htslib for mips/mipsel are most welcome.