- 2010.02.15 15:43 "Re: [Tiff] Using libtiff in Visual C++ 6.0", by Bob Friesenhahn
-
2010.02.15 18:19 "Re: [Tiff] Tiff Digest, Vol 69, Issue 9", by Spike McLarty
-
2010.02.17 12:36 "Re: [Tiff] Tiff Digest, Vol 69, Issue 10", by Weichao Wang
-
2010.02.17 14:41 "Re: [Tiff] Using libtiff in Visual C++ 6.0", by Edward Lam
- 2010.02.17 15:16 "Re: [Tiff] Using libtiff in Visual C++ 6.0", by Gerben Vos
-
2010.02.17 15:25 "Re: [Tiff] Using libtiff in Visual C++ 6.0", by Weichao Wang
-
2010.02.17 12:18 "Re: [Tiff] Using libtiff in Visual C++ 6.0", by Weichao Wang
- 2010.02.17 11:56 "Re: [Tiff] Using libtiff in Visual C++ 6.0", by Weichao Wang
- 2010.02.18 15:01 "Re: [Tiff] Using libtiff in Visual C++ 6.0", by Olivier Paquet
-
2010.02.17 12:18 "Re: [Tiff] Using libtiff in Visual C++ 6.0", by Weichao Wang
-
2010.02.17 14:41 "Re: [Tiff] Using libtiff in Visual C++ 6.0", by Edward Lam
-
2010.02.17 12:36 "Re: [Tiff] Tiff Digest, Vol 69, Issue 10", by Weichao Wang
- 2010.02.16 14:08 "Re: [Tiff] Using libtiff in Visual C++ 6.0", by Olivier Paquet
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. butOnly 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:
- You can't link a DLL with missing symbols like you can a .so
- 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. systemThat'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