Tcl Source Code

Logged In: YES 
user_id=7549

commited to HEAD.

Logged In: YES 
user_id=7549

Anyone linking to Tcl with Stubs might use any of 4 
combination: -MD, -MDd, -MT, -MTd.  Using -Zl when 
compiling tclStubLib.c will not place a link requirement to 
any of the above.  It'll have to one, sure, at link time, 
but having the compiler place a link requirement to any of 
these and you'll need to drop this into any source code 
you'll be using Tcl with:

#ifdef _MSC_VER
    // Only do this when MSVC++ is compiling us.
#   ifdef USE_TCL_STUBS
// Mark this .obj as needing tcl's Stubs library.
#pragma comment(lib, "tclstub" \
    STRINGIFY(JOIN
(TCL_MAJOR_VERSION,TCL_MINOR_VERSION)) ".lib")
#if !defined(_MT) || !defined(_DLL) || defined
(_DEBUG)
    // This fixes a bug with how the Stubs library 
was compiled.
    // The requirement for msvcrt.lib from 
tclstubXX.lib should
    // be removed.
#    pragma comment(linker, "-
nodefaultlib:msvcrt.lib")
#endif
#   else
    // Mark this .obj needing the import library
#   pragma comment(lib, "tcl" \
STRINGIFY(JOIN
(TCL_MAJOR_VERSION,TCL_MINOR_VERSION)) ".lib")
#   endif
#endif

It is perfectly valid to build an application that embeds 
Tcl with the static multithreaded run-time (aka -MT(d), 
libcmt(d).lib).  And if I build the app with symbols, and 
choose to use LoadLibrary(tcl84.dll); without symbols for 
Tcl, does it matter in the big picture?  If -Zl won't be 
added, I'll just do it myself for my own stuff, and 
probably leave that preprocessor work in my code anyways 
now that I think about it...

This trips many first time extension authors, BTW.

Logged In: YES 
user_id=90858

I am no VC++, but is this really the correct solution?
The bug report claims that extension developers will
want to do things like link debug code to a non-debug
build of Tcl and vice versa. I was under the impression
that this is exactly the sort of thing we wanted to
avoid. Would this not pull in two copies
of a given dll (the debug and non-debug versions) when
the extension in question is loaded into Tcl? I would
think that leaving the lib name in the .obj file is actually
a good thing and that adding -nodefaultlib:msvcrt.lib is
just silencing the real problem of mixed libs. If the app
is using the CFLAGS set by Tcl (like -MD or whatever)
then this would not be a problem, right?

Logged In: YES 
user_id=7549

It gets rid of the run-time linking requirement to 
MSVCRT.lib so only one flavor of it is ever needed.

Logged In: YES 
user_id=80530

Bug 230582:
http://sourceforge.net/tracker/index.php?func=detail&aid=230582&group_id=10894&atid=110894

Logged In: YES 
user_id=72656

I'm not able to find the original bug report by that number 
of name (in currently open reports).  What was this fixing?