Received: by whizzer.wpd.sgi.com (921026.SGI.NOSTRIP/911001.SGI)
	 id AA19107; Mon, 23 Aug 93 17:24:45 GMT
Received: from sgi.sgi.com by whizzer.wpd.sgi.com via SMTP (921026.SGI.NOSTRIP/911001.SGI)
	for /usr/people/sam/majordomo/wrapper resend -l tiff -h sgi.sgi.com -f tiff-owner -s -m "-oi -odq -om" tiff-list id AA19100; Mon, 23 Aug 93 10:24:41 -0700
Received: from jato-news.jpl.nasa.gov by sgi.sgi.com via SMTP (920330.SGI/910110.SGI)
	for tiff-relay@whizzer.wpd.sgi.com id AA25444; Mon, 23 Aug 93 10:24:39 -0700
Received: from jpl-devvax.Jpl.Nasa.Gov by jato.jpl.nasa.gov (4.1/SMI-4.1+xDXRm2.2)
	id AA15760; Mon, 23 Aug 93 10:24:37 PDT
Received: from tazboy.Jpl.Nasa.Gov by jpl-devvax.Jpl.Nasa.Gov (4.1/SMI-4.1+DXRm2.2)
	id AA04394; Mon, 23 Aug 93 10:24:36 PDT
Received: by tazboy.Jpl.Nasa.Gov (4.1/SMI-4.1+DXRs2.1)
	id AA04812; Mon, 23 Aug 93 10:25:13 TAN
Date: Mon, 23 Aug 93 10:25:13 TAN
From: ndr@tazboy.Jpl.Nasa.Gov (Niles Ritter)
Message-Id: <9308231725.AA04812@tazboy.Jpl.Nasa.Gov>
To: tiff@sgi.sgi.com
Subject: Re: libtiff on Alpha
Sender: tiff-owner@sgi.sgi.com

>  
>  Has anybody ported the library to the DEC Alpha? Our first effort, without
>  modifying anything, produced a library that fails in tif_readdir.c It looks
>  like the offset used in lseek fails since it is a long. Longs on the Alpha
>  are 8 bytes (64 bits), rather than 4 bytes as on most other platforms. It
>  seems fairly obvious to define/cast it as an off_t, but I suspect there will
>  be more to it than this...
>  
> [other related problems deleted].  

We were able to get the libtiff code to compile and run correctly in
an afternoon. I seem to recall that there are some compiler switches
which allow for backward compatibility with the 32-bit VAX/VMS machines.
which includes (I believe) forcing 32-bit longs. This is infinitely
preferable to trying to go back and rewrite all the byte-swapping
and bit shifting code for 64-bit longs, with no performance loss.

The switch is /STANDARD=VAX_C (VAXC?) for the VMS C-compiler. We also had
to #define BSDTYPES for the u_long stuff to be set correctly.
Other than that, I only recall a few other cosmetic changes in the
code proper.

...Or are you running the unix OS ? I haven't looked at the manual for
the C compiler under unix, but there is almost certainly a similar switch.

>  Also, there is a version of "xv" on the Alpha on which we are doing the
>  port. It behaves really strangely with TIFF files. I can't read any files
>  that were created on another system. I can, however, read a file that was
>  created on the Alpha (I saved the internal image as TIFF and it loads back
>  fine). Any ideas?
>  

Aha!

I suspect that you *are* using VMS. If so, do a "dir/full" on the transferred
files and see if the record format is "Stream_CR" or not. The libtiff
code uses "unix io", which gags very badly if the file is in fixed record
or variable-length record format. For example, doing a "read" on a fixed
record will only read in a single records' worth of data, even if you
requested more. In addition, you can only "seek" to record boundaries.
The files created on the Alpha work because they were forced to have
"Stream_CR" record format by the unix-io routines.

What we have usually found is that when files are transferred via FTP
to a VAX/VMS machine, the file structure could turn out to be any of
several different types, depending on which version of the VMS FTP
software was used, and which FTP commands are available.

Before you do the transfer, try the command "mode" to make sure that
the transfer is "stream". If not, give the command "mode stream".
Next, try the command "struct" to make sure that the file structure
is "file" (and not "RECORD" or "VMS"). Next, if you have the 
command "force", toggle the command until the response is,

  "Always use current transfer mode for file transfer."

If you don't have a "force" command, and both the host and client
are VMS, you might get away with setting "struct VMS", which will
(hopefully) preserve the file structure between the machines. 

Oh, yes, make sure that the transfer "type" is "binary" ("image").

It seems that just about every version of VMS FTP is different.
You will have to do a "help ftp" or help within ftp to see
which commands you will need to use. On very old versions, the
blasted FTP will *only* produce fixed record length files, which
means having to go low-level and use the "convert" utility, which
fiddles with the VMS record structures. Or write some C-code which
reads records and writes out streams.


  --Niles.



