2010.02.15 13:16 "[Tiff] Using libtiff in Visual C++ 6.0", by Weichao Wang

2010.02.18 17:41 "Re: [Tiff] Using libtiff in Visual C++ 6.0", by Phillip Crews

On 2/18/2010 10:01 AM, Olivier Paquet wrote:

jcupitt@gmail.com wrote:

On 16 February 2010 17:40, Kevin Myers<kmyers1@clearwire.net> wrote:

I used to think that linking on *nix systems could get a little hairy,
it seems like it's fairly straightforward compared to Windows. but

Only if you always build everything from source using the same compiler. Otherwise, in practice, it gets as bad or worse than windows for C++. In building the same application on windows and linux, it's been my experience that the very strict isolation of symbols in DLLs on windows leads to fewer headaches (as in: if it links cleanly, it won't crash at runtime). As I understand it, this is mostly because:

  1. You can't link a DLL with missing symbols like you can a .so
  2. Any given import is looked for in one and only one predefined DLL at

runtime (vs ELF's "lets's search for it everywhere except here and here but also here if flag XYZ was used...").

Of course that system is also less flexible and complicates some designs.

MSVC 6.0 also uses this runtime, so projects built with this compiler
work with the libtiff DLLs. should

Sadly, later MSVC versions use a different runtime, usually called
or some higher number. MS changed the runtime name msvcrt70.dll,
the runtime doesn't just supply functions like malloc, printf because
friends, it also supplies basic parts of C++, like the functions and
exception handling. MSVC7 and later have a new exception supporting
that breaks binary compatibility. system

That's mostly correct AFAIK.

So... versions of MSVC later than 6.0 will be unable to link against

the libtiff DLLs.

But this not quite. It would be true for a static library (because then there is only one runtime) but you can very well use several DLLs which themselves use different C++ or C runtimes in the same application. You just need to avoid doing malloc() of memory in one DLL and free() of it in another (which is bad design anyway).

The real issue, as Bob said, is the lack of an import library which VC will understand. Hence the need to find another DLL or build one.

I've never tried it but the source suggests it should be as simple as opening a command prompt, running "vcvars.bat" (or whatever it was called back then) from the visual studio directory to setup the command line build environment and then running this from the libtiff source directory: nmake /f makefile.vc all

This should produce a .dll and a .lib. Using the dll is then a matter of adding the .lib to the list of libraries to be linked to the project. I forget exactly where in VC6 but it should be in the project options, probaly under the "Link" or "Linker" tabs.

These issues are part of the reason to link statically whenever possible. It avoids an enormous number of build and especially run-time (customer) problems.

Executables linked statically with later versions of MSCRT can run fine on earlier operating systems, though at some point compatibility with Windows 95/98/ME will probably break (and may already have; I don't support those O/Ses any more).

- Phillip