0

I've searched for a couple days and can't find an answer to my question, which seems to be different but related to other questions people have asked, so I'm posting a very specific question.

I have a Managed C++ assembly that my "customers" use to link with C#/.NET projects. This assembly pulls in the OpenSSL static c++ libraries without issue, but will not pull in my unmanaged C++ static library (call it "MyLib.lib").

At first this was because "MyLib.lib" used static linking of the CRT, but I switched it to use the DLL version of CRT. Unfortunately all that did was change the problem.

Now when I compile my Managed C++ assembly, it's looking for "MyLibmdd.lib" -- which of course does not exist. Why would it look for such a thing when I've specified the linker input as "MyLib.lib"? And what does it think is in "MyLibmdd.lib", and why does it require it to exist?

It doesn't require "libeay32mdd.lib" or "ssleay32mdd.lib", so why is it treating my static library differently?

Ultimately, I know I should be able to pull "MyLib.lib" into the Managed C++ project because others have done it (including OpenSSL). So it would seem there's just something I'm unaware of reguarding how "MyLib.lib" should be built.

Any ideas what things I should double-check at this point? I'm using Visual Studio 2013.

Thanks!

Phil
  • 5,822
  • 2
  • 31
  • 60
Bungles
  • 1,969
  • 2
  • 25
  • 54
  • There are different builds to link against. When linking to DLL CRT you selected it to be multithreaded and debug (this is what mdd suffix is about). Linker assumed you have different builds of your lib as well and looking for similar suffix to be sure all libs are matching – Severin Pappadeux Apr 30 '15 at 17:18
  • Not sure I follow. "MyLib.lib" was compiled with /Md, as was the Managed C++ assembly. So the Managed C++ assembly should already have what it's looking for. I tried removing "MyLib.lib" from the linker input on the Managed C++ assembly project, but then it complained it couldn't find "MyLib.lib". So I put it back and now it wants "MyLibmd.lib" (in release mode). Why does it need two versions of the .lib? If it does, then why isn't the "MyLib.lib" project spitting out two .lib files? And again, it's not looking for the same thing from other, open-source .lib files. – Bungles Apr 30 '15 at 19:37
  • There are problems to have debug and release libraries linked together. So from what I know MyLib.lib is considered to be name of the "library family". Which particular library is linked is defined by the suffix which is automatically added from compilation settings. You really have to have at least two libs (one Debug and one Release) for a given compiler setup and make an appropriate suffix http://stackoverflow.com/questions/11658915/mixing-debug-and-release-library-binary-bad-practice – Severin Pappadeux Apr 30 '15 at 21:09
  • I do have one debug and one release version of MyLib.lib. They have the same name but go into different folders "debug" and "release" folders. Since I'm manually naming my output files to MyLib.lib, do I need to add the suffixes "md" and "mdd" myself in the output name field? I figured if I specified the output name MyLib.lib and then in the consuming project it specifically linked against MyLib.lib, everything should just match up, right? – Bungles Apr 30 '15 at 21:26
  • I think so, but you ought to try. From my experience, when I rebuild and use BOOST libraries (from www.boost.org) during build I get all libraries done (debug, release, mt, st) and suffixes are appended to indicate which one is debug or release or ... . After that proper library is linked when I build my application – Severin Pappadeux Apr 30 '15 at 21:30
  • Does MyLib by chance have ```#pragma comment(...)``` anywhere in the source? – Alex Apr 30 '15 at 23:36
  • Ok, I'm fine with trying but what is it exactly I'm trying? – Bungles May 01 '15 at 00:26
  • Yes, there are a crap-ton of #pragma comment(...) lines... – Bungles May 04 '15 at 04:38

1 Answers1

0

The problem was indeed that there were #pragma comment(...) lines in a number of places that prevented naming the output libraries my way. Commented those out and all seems well so far.

Bungles
  • 1,969
  • 2
  • 25
  • 54