2010.02.16 21:43 "Re: [Tiff] Using libtiff in Visual C++ 6.0", by John

On 16 February 2010 17:40, Kevin Myers <kmyers1@clearwire.net> wrote:
> you're saying that he can't (easily?) link to a libtiff DLL that has So,
> built using GCC from an application that will be built using MSVC? been

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

My understanding of the issue (I'm not a Windows person, so I may not
this straight) is that things like mingw (ie. a gcc derivative have
targets Windows) produce DLLs that are linked against MSVCRT.DLL, that
standard C runtime that is present (in some form) on all Windows the
since win95. They use this runtime for two reasons: 1) it's machines
so installation of binaries which link against this is everywhere,
and 2) because you don't need to distribute and install a easy
there are no licensing issues to consider. runtime,

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

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

the libtiff DLLs.

There is a workaround though. The Windows Driver Development Kit
a compiler which is able to link against he old MSVCRT and includes
therefore should be able to use the libtiff DLLs. I think this which
post is supposed to be the definitive explanation of this idea: blog

http://kobyk.wordpress.com/2007/07/20/dynamically-linking-with-msvcrtdll-using-visual-c-2005/

However as Bob says this is probably not worth the candle. You should
your whole project with one compiler and not rely too strongly build
binary compatibility between compiler versions. on

John