Re: [64 bit] ghostscript configure script doesn't recognize libtiff

[Charles Wilson <cygwin at cwilson dot fastmail dot fm>]

On 4/23/2013 4:21 AM, Corinna Vinschen wrote:
> On Apr 23 06:55, Dr. Volker Zell wrote:
> > I need help compiling ghostscript for 64 bit. The configure script doesn't
> > recognize libtiff somehow. Any ideas ?
>
> Yes.  libtiff-3.9.7-2 is apparently 32 bit:
>
>    $ file /bin/cygtiff-5.dll
>    /bin/cygtiff-5.dll:   PE32 executable (DLL) (console) Intel 80386, for MS Windows
>
> After reinstalling Yaakov's 3.9.7-1:
>
>    $ file /bin/cygtiff-5.dll
>    /bin/cygtiff-5.dll:   PE32+ executable (DLL) (console) x86-64, for MS Windows

Weird. I double checked that I was using "cygport --64" when building 
that package (using the cygwin-ports cross environment), so I think 
there must be a bug in stock cygport -- or an infelicitous interaction 
between it and tiff's configury -- that prevents "--64" from doing the 
right thing. (Or my 32->64 environment might be messed up somehow, I 
guess. Just trying to cover all the bases...)

If I have to use a non-stock cygport, then I might as well use non-stock 
in the 64bit environment itself, and build "natively".  I'll switch to 
that in the future.

> I removed the 3.9.7-2 packages and regenerated setup64.ini.  Please
> reinstall libtiff5-3.9.7-1 and libtiff-devel-3.9.7-1, that should get
> you going.
>
> Chuck, do you want to rebuild a new 64 bit tiff package set?

Yes. I also have a 4.0 'test' version ready for both 32 and 64, but I 
guess it's back to the drawing board for that, for x86_64, as well...

> Btw., when
> uploading can you make sure that all package files are group writable?

Ack.

> Also, make sure the tiff package doesn't depend on libstdc++6-devel.
> That package doesn't exist anymore.

Hmm...another symptom of cygport --64 actually operating in 32bit mode, 
at least in this case.  Those .hints are autogenerated, and on the 32bit 
platform libstdc++6-devel exists and is a correct dependency of 
libtiff-devel.

I'll double check that this issue is not present when I rebuild within 
the "native" 64bit environment.

--
Chuck