Tests fail on bigendian platforms

Create issue
Issue #96 new
Former user created an issue

As per $SUBJ running tests on s390 or ppc64 machines will make them fail.

As an attachment adding full build log from s390 machine.

2 possible things could be happening: 1) mo file is broken 2) mo file has different order on Big endian machines and there should be one more fixture.

Comments (8)

  1. Matěj Cepl

    And yes, it is definitively issue of big/little-endian. When comparing first few bytes of the expected and observed strings (see attachments), these are: (expected)

    \xde\x12\x04\x95\x00\x00\x00\x00\xdd\x02\x00\x00
    

    and (observed)

    \x95\x04\x12\xde\x00\x00\x00\x00\x00\x00\x02\xdd
    

    Which are identical except for their endianness. I guess the possible culprits are in functions _BaseFile.to_binary() and _BaseFile._readbinary() which are the only two places where struct library is used. And yes both format strings in those functions (for struct.pack() and struct.unpack() respectively) are without any qualifiers, so these are by default in their native order. I don't know what's the expected endianness according to the gettext standard, but if it is little-endian, then I can see the conflict.

  2. Jakub Wilk

    msgfmt used to create native-endian MO files, but it defaults to little-endian these days:

    Version 0.19.8 - June 2016
    
    * Support for reproducible builds:
      - msgfmt now produces little-endian .mo files by default.
    
  3. Jakub Wilk

    Apart from struct.pack(…) there's also array.array("i", offsets).tobytes() that produces native-endian data.

  4. Log in to comment