1993.08.23 10:25 "Re: libtiff on Alpha", by Niles Ritter
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...
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.