Re: Linking libraries
On Jul 3, 11:34 am, "Alf P. Steinbach /Usenet" <alf.p.steinbach
+use...@gmail.com> wrote:
* Giuliano Bertoletti, on 03.07.2010 08:58:
Now, the question is: if the library is only a collection of
.objs and does not carry libc and other things around, why
should one worry to compile and distribute it under one (or
all) of the 3 different MSVC++ settings -ML, -MD or -MT?
Also, why MSVC++ lists these settings under the compiler
settings (and not the linker). After all, which distinction
in code generation is to be made at compile time depending
whether I use the single or multithreaded static version ?
It's possible to produce runtime-lib agnostic libraries also
with MS tools, but mostly that's just an academic possibility.
I did try it at one time. I can't recall exactly what the
problems were, but it turned out to be impractical.
From discussions with people at Microsoft, this is supposedly
fixed in VC10. At least with regards to the C++ library.
(There's no problem with the C++ library in VC8, either. As
long as you don't use std::string:-).)
Given that there's no such problem with *nix tools, it's clear
that there's no technically compelling reason for the
impractical way that the MS tools work, introducing needless
high complexity for the build process with umpteen variants of
every object and library file.
Yes and no. The MS tool chain could certainly be a lot easier;
in particular, it would be nice if they were to make a clean
break between the C (libc in the Unix world) and the C++, and
bundle the C part with all of their systems. On the other hand,
you can easily encounter many of the same problems under Unix,
as soon as the library itself also uses the standard C++
library. (We currently have more problems under Solaris than
under Windows.)
--
James Kanze