Big-endian build issues

[GoogleCodeExporter]

Is anyone building tesseract-3.01 on a big-endian machine?   I've been able to 
build it on several little-endian platforms including linux (x86), Solaris 
(x86), and darwin (Mac OS/X x86_64).  However,  on Solaris (sparc) I'm running 
into issues that I think may be due to the endian-ness of the machine.

One obvious problem is this block of code in dict/dawg.cpp:

  int unicharset_size;
  fread(&unicharset_size, sizeof(inT32), 1, file);
  fread(&num_edges_, sizeof(inT32), 1, file);
  ASSERT_HOST(num_edges_ > 0);  // DAWG should not be empty

  if (swap) {
    unicharset_size = reverse32(unicharset_size);
    num_edges_ = reverse32(num_edges_);
  }
  Dawg::init(type, lang, perm, unicharset_size, debug_level);

The ASSERT_HOST() macro needs to moved after the value is fixed up by
the if(swap) block.

After a few other minor portability tweaks (like supplying a replacement for 
stdint.h) the code builds and runs.   However, the "recognized" text from 
phototest.tif is just garbage.  I'm not sure how to go about debugging that.

Original issue reported on code.google.com by psfa...@gmail.com on 28 Oct 2011 at 6:46

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

can I close this issue or is it still valid?

Original comment by zde...@gmail.com on 31 Oct 2011 at 5:00

[GoogleCodeExporter]

There is a a bug that needs to be fixed.

The line:

  ASSERT_HOST(num_edges_ > 0);  // DAWG should not be empty

needs to be moved after the if(swap) block because num_edges doesn't have the 
correct value until that point on the big-endian machines.

Original comment by psfa...@gmail.com on 1 Nov 2011 at 2:09

[GoogleCodeExporter]

Position of ASSERT_HOST fixed in 3.02.
Please close or re-open if other problems persist.

Original comment by theraysm...@gmail.com on 3 Feb 2012 at 3:38

• Changed state: Fixed