Bug 691996 - Problem with cross-compiling
Summary: Problem with cross-compiling
Status: NOTIFIED FIXED
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: Build Process (show other bugs)
Version: 8.71
Hardware: PC All
: P2 normal
Assignee: Robin Watts
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-02-22 18:54 UTC by Marcos H. Woehrmann
Modified: 2012-04-12 17:13 UTC (History)
0 users

See Also:
Customer: new customer
Word Size: ---


Attachments
arch.h (1.28 KB, text/plain)
2011-02-22 19:01 UTC, Marcos H. Woehrmann
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Marcos H. Woehrmann 2011-02-22 18:54:46 UTC
The customer reports:

The problem is that one of the images in the attached PDF file prints almost entirely as a black rectangle when the PDF is processed on our target architecture (Big-Endian PowerPC, GS cross-compiled on a x86 linux host).
There is no problem when GS is running natively on x86 linux, using the same configuration options and romfs resources. I've also run GS on a Big-Endian Sparc machine running Sun Solaris, which has no problems either.
 
Printing the PDF through a windows driver, converting it to Postscript before it is passed to GS gives the same results.
 
I've captured the output of an unmodified bmpmono device, running in 180 dpi, on ppc and x86 architectures.
The attached bmpmono_ppc.bmp shows the black rectangle, where the bmpmono_x86.bmp prints the image of a barcode.
Comment 1 Marcos H. Woehrmann 2011-02-22 18:55:14 UTC
Further customer information:

Some additional information regarding the problem described in the mail below:
we found that when printing this PDF with Adobe Reader with the advanced print option 'let printer determine colors' enabled, the problem goes away. It seems that Adobe Reader converts the images into a different format, using different colorsettings.
I'm attaching the resulting Postscript files as reference, where PDFTest_prn_colors.ps is the file that prints correctly on our printer, and PDFTest.ps prints as a black box.
 
It looks like there's something wrong with the handling of a certain colorspace on our PowerPC target.. This file prints correctly with the same GS configuration on a native x86 system.
 
Note that the 'detailed bitmap debug info' (-ZB debug flag) shows the same results on PowerPC and x86, so at that point the bitmap still seems correct. I've attached PDFTest_bad-ZB.log that shows the -ZB debug output as reference.
Comment 2 Marcos H. Woehrmann 2011-02-22 18:55:53 UTC
And more customer comments:

No other relevant Ghostscript options were used, only -dNOPAUSE.
Note that resolution doesn't seem to matter, nor does the outputdevice.
I tried pcxmono and bmpmono at 300x300 today, which show the same problem.
Also tried the grayscale device 'pcxgray' without success.

Note that I attempted to duplicate this problem on a big-endian sun-sparc unix system, but couldn't get it to fail either. I only see the problem with GS running embedded in our PowerPC based printer (8241 family PowerPC, 32-bit, big endian)..

GS is built with only the following enabled features:
FEATURE_DEVS=$(PSD)psl3.dev $(PSD)pdf.dev
Comment 4 Marcos H. Woehrmann 2011-02-22 19:00:07 UTC
Robin had some suggestions in an email:

Cross-compiling GS is a tricky business, due to the way we do the
build; we build various executables during build that are expected to
run on the host machine (such as gsecho etc), and some that are
(AIUI) expected to be run on the target machine (genarch).

This is made worse by autoconf etc - it's very easy to configure for
the host instead of the target and not realise.

When I build for ARM targets for instance, I tend to run the autoconf
on an x86 machine, and tweak the produced files by hand - fortunately
as x86 and (most) ARMs are all little endian there are fairly few
differences, so this works for me. Ray may have more experience in
doing this 'properly'.

I'd like to ask the customer to:

 1) do a completely clean build and record the logs for us to look
  at (so we can see all the build steps he does, commands and all)
 2) to get the produced arch.h file for us to check
 3) to get him to send us a diff of his changes from the vanilla 8.71
  sources.
Comment 5 Marcos H. Woehrmann 2011-02-22 19:01:58 UTC
Created attachment 7277 [details]
arch.h

This is the arch.h file generated when I natively compile on an iMac G5.
Comment 7 Robin Watts 2011-05-25 15:36:39 UTC
This was fixed in revision 12205 in SVN (http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=7d3b6018360889d13b08be40bc8ac1a63baba8be).

Was due to floating point rounding issues.