views:

591

answers:

2

I don't know if it's possible to do this, but I would like the /NODEFAULTLIB to be applied to a static library project.

I have many application projects (A.exe, B.dll, C.dll) that use a common static library D.lib. This library has a lot of code and also has other .lib dependencies as well. One of them is the openssl library, which seems to have been built for win32 against the Release version of the CRT (i don't have the original project/sources).

So far, to avoid the mixing of the Release/Debug versions of CRT, I have to put the /NODEFAULTLIB:msvcrt.lib linker directive in all leaf projects (A.exe, B.dll). This works but I think it's not the ideal way of dealing with that issue. I tried to put this property in D.lib project, but it has no effect.

Is there a way to force msvc++ to ignore the msvcrt.lib dependency from the 3rd party library?

A: 

My understanding is that if library LIB in linked statically into a DLL, the DLL contains already all relevant code from LIB. Therefore, this coupling cannot be removed. This is just based on my understanding of statical linking, not on experiments.

Weidenrinde
+1  A: 

A .lib does not have any linker settings because you don't link it, you link to it. A .lib is just an archive of .obj files, sort of like an uncompressed .zip file - that's why you have to put the setting on all projects that link to it.

If you're using VS2005+ you could use property sheets so that you only have to put the setting in one place and then use that property sheet in all projects.

However, OpenSSL is just that - Open Source, so you should be able to get the source for the version you are using and build it again (and add it to your version control system of course). I thought OpenSSL could be built as a DLL or LIB, which would solve your problem as the DLL would not interfere with the linking of your code.

Failing that, you always have the option of slitting your functionality out into a separate DLL so that you only have issues with one project.

Chris Oldwood
I think the claim in your first paragraph is incorrect -- certainly if I compile a C file to .OBJ with CL.EXE (and without using the /Zl switch), a "/DEFAULTLIB:xyz" (where xyz is typically "MSVCRT" for /MD compilation, "LIBCMT" for /MT etc.) is added to the .drectve section of the .OBJ file, and this persists into the .LIB file. If that .OBJ is required when linking against the .LIB file, then the directive will be honoured, leading to linker warning "LNK4098: defaultlib 'LIBCMT' conflicts with use of other libs; use /NODEFAULTLIB:library" if other .OBJs have requested different a CRT lib.
j_random_hacker
OK, that statement was a generalisation. You can use "#pragma comment" along with lib/linker to pass additional directives to the linker via a .obj file in a .lib.
Chris Oldwood