LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
February 2010
Previous Thread
Next Thread
Previous by Thread
Next by Thread
Previous by Date
Next by Date
Contact
The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems
Thread
2010.02.18 15:59 "Re: OT: Visual C++ runtimes (was: Using libtiff in Visual C++ 6.0)", by Edward Lam2010.02.18 17:41 "Re: 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, >> but it seems like it's fairly straightforward compared to Windows. >> > 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 >> should work with the libtiff DLLs. >> >> Sadly, later MSVC versions use a different runtime, usually called >> msvcrt70.dll, or some higher number. MS changed the runtime name >> because the runtime doesn't just supply functions like malloc, printf >> and friends, it also supplies basic parts of C++, like the functions >> supporting exception handling. MSVC7 and later have a new exception >> system that breaks binary compatibility. >> > 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