TIFF and LibTiff Mail List Archive


2000.04.17 19:03 "SGI tiff 3.5.5 make install error .....", by Hezekiah Mcmurray
2000.04.18 14:42 "Re: SGI tiff 3.5.5 make install error .....", by Jan Prikryl
2000.04.18 18:00 "Re: SGI tiff 3.5.5 make install error .....", by Sam Leffler
2000.04.18 19:29 "Re: SGI tiff 3.5.5 make install error .....", by Frank Warmerdam
2000.04.19 02:19 "autoconf based configure", by Kiriakos Georgiou

2000.04.18 19:29 "Re: SGI tiff 3.5.5 make install error .....", by Frank Warmerdam

If someone does come up with a fix for this, I'd like to apply it to the CVS source quickly.

Otherwise, if anyone could donate shell access to an SGI Irix box that we could use for testing builds (or at least quickly fixing this problem), we'd greatly appreciate it.

Here is the patch... tested on Irix 6.5. Shall be appiled in the root directory of libtiff with

        patch -p0 < tiff-makefile.patch

By the way, the install part of current makefiles seems to be SGI-specific (at least it relies on SGI-specific /sbin/install). It will probably not work on many architectures (it sure does not work on my Linux). It could pay off to switch libtiff to automake/autoconf, has anyone done anything in this direction already?


I have applied your patch, and verified that it makes things work on the SGI I have access to.

I am supportive of switching to a autoconf/automake/libtool based install; however, I am worried there will be some degradation on some platforms. For instance, the loss of the SGI specific install logic. I also dislike using libtool in packages I am doing active development, but I think I can learn to deal with it.

I have recently deployed PROJ.4 using autoconf/automake/libtool and that worked reasonably well. If there aren't too many objections, perhaps Mike and I can look at switching libtiff over the next few months.

In deference to Chris Hanson's objection, I agree that it is desirable to retain the current organization of source, and perhaps to distribute a dead simple non-configure based Makefile for the libtiff and tools directories. This could be easily hacked for "problem" platforms. Also, NMAKE and other build mechanisms for non-Unix platforms can be retained.

My main concern is that a shift to a new configuration mechanism will cause hassles for a while. Files that get forgotten, DSO support that might be lost of some platforms. However, it might make it practical to make libtiff configuration "smarter" about stuff like using libjpeg, libz and other stuff if available on the system.

Best regards,

I set the clouds in motion - turn up   | Frank Warmerdam,
light and sound - activate the windows |
and watch the world go round - Rush    | Geospatial Programmer for Rent