AWARE SYSTEMS
TIFF and LibTiff Mail List Archive

Thread

2007.06.29 11:04 "[Tiff] Suggested Source Changes for Building libtiff Under Windows", by Kevin Myers
2007.06.29 12:49 "Re: [Tiff] Suggested Source Changes for Building libtiff Under Windows", by Frank Warmerdam
2007.06.29 18:18 "Re: [Tiff] Suggested Source Changes for Building libtiff Under Windows", by Kevin Myers
2007.06.29 13:12 "Re: [Tiff] Suggested Source Changes for Building libtiff Under Windows", by Andrey Kiselev
2007.06.29 19:58 "Re: [Tiff] Suggested Source Changes for Building libtiff Under Windows", by Kevin Myers
2007.06.30 07:29 "Re: [Tiff] Suggested Source Changes for Building libtiff Under Windows", by Kevin Myers
2007.06.29 15:17 "Re: [Tiff] Suggested Source Changes for Building libtiff Under Windows", by Bob Friesenhahn

2007.06.29 19:58 "Re: [Tiff] Suggested Source Changes for Building libtiff Under Windows", by Kevin Myers

Hello Andrey,

Thanks for your reply. Please see below for individual replies to your comments.

Kevin M.

"Andrey Kiselev" wrote in part:

<snip>

Thanks for your suggestions, but I should note that we have nothing with gnuwin32 build of libtiff. We are only distributing sources of the library, not binary builds. The official place to get libtiff is

As mentioned in my reply to Frank, I will contact the GnuWin32 people separately.

Warnings related to this problem are boring a bit, but actually harmless. I will fix it, however.

Thanks. :-) The compiler warnings can be a significant headache for someone like me who doesn't build things very often, and can't easily discern warnings that are a real problem from those that aren't. In my numerous attempts at building libtiff over the last few days, many of my unsuccessful builds included compiler warnings that *were* problems. So, it would definitely help if you could implement changes that would remove warnings that really aren't problems. Then folks like me will know there is a better chance that any warnings received when building are likely to be something that really needs to be looked at.

In the above regard, I would also suggest adding a comment in the build documentation about any warnings that are routinely expected, such as the warnings that are generated about function calls without arguments (appears to result from passing the actual functions themselves as arguments). I wonder if these warnings could be eliminated by providing dummy arguments for functions that are passed as arguments in this manner?

I do not fully underatand a problem here. tif_config.h should be built from tif_config.h.vc by copying in MSVC environment and tif_config.h.vc is manually adopted for MSVC. Sometimes this file is not being properly built. It happens if your are building using MSVC and autotools from the same source tree. I should improve makefile.vc rule for tif_config.h to fix this problem. But I really do not see any problem with current tif_config.h.vc.

Upon further review, I need to look at my suggested changes for this file much more closely. I will get back to you once I have completed that process. I now know that at least one of the changes that I suggested was inappropriate.

> 7. Improve cross-package handling for HAVE_STD_LIB_H.

>

> The jpeg library developers should be asked to replace their current > handling in jconfig.h for HAVE_STDLIB_H with the following:

>
> #ifndef HAVE_STDLIB_H
> #define HAVE_STDLIB_H
> #endif
>
> Until this change can be implemented, GnuWin32 documentation for

> building libtiff using MSVC should advise that it may be necessary for > the developer to replace the existing line in jconfig.h that defines

> HAVE_STDLIB_H with the above block of code in order to avoid problems > building libtiff due to a difference in the definition of this item.

Hmm, libjpeg needs few tricks to be successfully built, but I never needed above change. By the way, what libjpeg version do you use? If libjpeg is being built using corrsponding instructions for MSVC it should be perfectly compatible with libtiff. Another story with mingw, but MSVC works well.

The jpeg library that I used was jpeg-6b-4 downloaded from from the GnuWin32 web site. Since the source from that web site was already set up to build under Windows, I assumed that no changes to any corresponding source files such as jconfig.h and jmorecfg.h would be required.

Upon further review after receiving your comments, the specific problem described above actually resulted from an inappropriate setting in the tif_config.h.vc that I was using. So please disregard item 7 regarding the above issue from my prior message.

However, while looking back at all of the above I noticed another change that I had to make in jmorecfg.h that *did* result in compiler errors while building libtiff if left unchanged. The jmorecfg.h that I was using contains the following block of code:

#if (defined (_MSC_VER) && (_MSC_VER >= 800))
#define HAVE_UNSIGNED_CHAR
#define HAVE_ALL_INTS
#define EXTERN(type) extern type __cdecl
#endif

I had to comment out the #define HAVE_ALL_INTS, otherwise a block of code that includes typedefs for UINT8 and UINT16 (among other things) is bypassed, and this causes problems when the libtiff build tries to process jpeglib.h, which contains items that are defined as types UINT8 and UINT16.

> 8. Add a port.h header file for modules located in the port > subdirectory.

That could be a good idea, thanks!

Glad that at least some of what I provided was helpful. Sorry for the mistakes noted above.