============================================================================ What are Threads intricasies of MySQL ? CMakeLists.txt comments in mysys dir: # Only the server link with this library, the client libraries and the client # executables all link with recompiles of source found in the "mysys" directory. # So we only need to create one version of this library, with the "static" # Thread Local Storage model. # # Exception is the embedded server that needs this library compiled with # dynamic TLS, i.e. define USE_TLS TOP/mysys: mysys CMakeLists.txt just declares source files and creates lib. (simple). client: mysqltest.cc, mysqlslap file is compiled with -DTHREADS And just linked with mysqlclient mysys regex dbug etc. Other files are not compiled with -DTHREADS; But all are linked with same libraries. Question: Does static library have static dependency with thread or non-thread lib ? i.e. Can a static lib link with single or multi-threaded program ? From http://www.eggheadcafe.com/software/aspnet/32429133/creating-static-lib--tips.aspx There's a lot of aspects you should consider when distributing static libraries. The most important is the "Runtime library" used. This is usually a choice of the end user, but each static library linked in a project should be compiled with the same setting. For example, you can get troubles if you distribute your static library with a release multithreaded DLL , and the user uses a "debug multithreaded" option. So , to be sure, you should distribute 4 versions of your DLL : 1 - Debug , runtime = multithreaded 2 - Debug , runtime = multithreaded DLL 3 - Release , runtime = multithreaded 4 - Release , runtime = multithreaded DLL name it with different names, and let the user select the most suitable. To solve this problems you can do a DLL and choice one the runtime option that you want. To avoid reverse engineering you should not distribute the PDB files, but only the lib files. This should be enought. You can also disable symbolic informations from your project. As above, I'm not sure that static lib is the best distribution choice, unless you write simple C libraries. From http://www.gamedev.net/reference/articles/article1583.asp The calling convention in a VC++ project defaults to _cdecl (/Gz). However, there exist other calling conventions that are more efficient (i.e _stdcall /Gr ). We cannot assume clients will use _cdecl as the default, therefore we should declare the calling convention in every interface function exposed in the static library header file. If not, differing calling conventions in the client and the precompiled library usually result in an unresolved error during linking. C Runtime Library More often than not, your static library uses standard C functions. The static library then compiles with the C runtime libraries. The problem is there are several versions of the runtime library - single, multithreaded, and multithreaded DLL, as well debug versions of those, making a total of 6 versions (/ML, /MT, /MD, /MLd, /MTd, /MDd). The static library compiles with one version; the client can compile with another. A conflict occurs and usually, a warning is generated. The solution is 1. Force the client to link the same runtime library as our static library. 2. Provide 6 different versions of the library. To me, Solution 1 is unacceptable, yet I see it almost all the time (even in professional packages which I will not name). My solution is 1. Provide 6 different versions of the static library 2. Define a naming convention for naming the .lib file. 3. Provide a name decoration scheme that links in the correct .lib file based on client project settings For the naming convention, I append the .lib with a suffix that distinguishes the runtime library linked. So, for example, if my static library is called MyLibrary, I have six .lib files: MyLibrary.lib // single threaded MyLibraryMT.lib // multithreaded MyLibraryRT.lib // multithreaded dll MyLibraryD.lib // debug versions MyLibraryMTD.lib MyLibraryRTD.lib VC++ 6.0 automatically defines the _DEBUG, _MT and _DLL based on the runtime library linked. The moral of the story is compile the static library with exceptions enabled (/GX) and RTTI (/GR). Tip: Compile the static library with debugging information. One important thing to take note is with debugging info enabled, the client can reverse engineer your static library. If this is not acceptable, then compile with the Line Number Only (/Zd). This gives the debugger access to public functions and data only (which of course the client should have access to already). ============================================================================ http://wiki.codeblocks.org/index.php?title=FAQ has some info. ============================================================================ Interesting Article: Library Problems: http://bcbjournal.com/special_issue/bcbj_vol14_num5.7.pdf?PHPSESSID=30ffa36c16e952a23ec81ee5d67fe49c Tip: Usually static libraries are built in Multithreaded mode ??? ============================================================================ Why should we have multiple libraries for single threaded and multi threaded,etc ? From: http://stackoverflow.com/questions/521972/why-is-runtime-library-a-compiler-option-rather-than-a-linker-option One side effect of the C preprocessor definitions like _DLL and _DEBUG that zdan mentioned: Some data structures (such as STL containers and iterators) may be sized differently in the debug runtime, possibly due to features such as _HAS_ITERATOR_DEBUGGING and _SECURE_SCL. You must compile your code with structure definitions that are binary-compatible with the library you're linking to. If you mix and match object files that were compiled against different runtime libraries, you will get linker warnings such as the following: warning LNK4098: defaultlib 'LIBCMT' conflicts with use of other libs These options may add defines (__DLL and __DEBUG for example) that are used in the runtime library header files. One common thing to do is to add __declspec(dllimport) to function declarations when linked dynamically. The compiler also seems to use these to assist the linker in linking to the correct libraries. This is explained in the MSDN. ============================================================================ Very Good Article describing different semantics of these options: http://msdn.microsoft.com/en-us/library/2kzt1wy3%28VS.80%29.aspx Which compiler option to use ? /MD[d] - Link with Multi-threaded DLL; Your application now depends on MSVCR80.DLL; It is linked with proxy MSVCRT.lib; (Use /MDd to link with debug version) Also defines _MT and _DLL; Note: If you also use /D_STATIC_CPPLIB, it will link with static c++ lib libcpmt.lib; /MT[d] - Link with Multi-threaded Static Library; Your app is linked with LIBCMT.lib library; (Note: LIB prefix usually implies static lib) Also defines _MT; /LD[d] - Creates DLL; Creates .lib import library for others to use; By default /MT assumed (i.e. our library depends on C Static library) unless /MD specified. (In that case, this library depends on dynamic C library). Note: The single-threaded CRT (libc.lib, libcd.lib) (formerly the /ML or /MLd options) is no longer available. Similary C++ single threaded libcp.lib and libcpd.lib also no longer available. Question: How to link with Single threaded C Runtime/Static Lib ? Ans: The C library is available only in Multi-threaded version. Single thread application can link with this multi-threaded enabled library. (this is true for any multi-threaded library if it is carefully written for binary compatibility). Question: Using /LD produces multi-threaded DLL or single threaded DLL? Ans: Depends on whether _MT is defined ??? ============================================================================ C Runtime Libraries Summary: http://msdn.microsoft.com/en-us/library/abx4dbyh%28v=VS.80%29.aspx ============================================================================ If you have more than one DLL or EXE, then you may have more than one CRT, whether or not you are using different versions of Visual C++. For example, statically linking the CRT into multiple DLLs can present the same problem. Developers encountering this problem with static CRTs have been instructed to compile with /MD to use the CRT DLL. Now that the CRT DLL has been renamed to msvcr80.dll, applications may have some components linked to msvcrt.dll and others to msvcr80.dll. If your DLLs pass CRT resources across the msvcrt.dll and msvcr80.dll boundary, you will encounter issues with mismatched CRTs and need to recompile your project with Visual C++ 2005. If your program is using more than one version of the CRT, some care is needed when passing certain CRT objects (such as file handles, locales and environment variables) across DLL boundaries. For more information on the issues involved and how to resolve them, see Potential Errors Passing CRT Objects Across DLL Boundaries. ============================================================================