0

In a (console) application developped in C++, I need to add a new function to a Framework.dll we developped. This new function in the Framework will use classes of a static lib that is provided to us.

I linked the static lib to our framework, and everything worked fine. Then I started editing the Framework's code to use a class of the static library. The framework still build without warning. When running the main app (that uses Framwork.dll), the app won't then start. It won't event go to the main(). It locks on an empty prompt and endlessly waits.

If I link the static lib directly into the application, I get no issue. But that's not where I want to use it.

Has anybody an idea of what I'm doing wrong?

NonoxX
  • 134
  • 10
  • Perhaps the problem is unrelated to the static library. Do you use aVast? If so disable it and try again. – drescherjm Oct 25 '17 at 15:09
  • For me you are trying to do the same thing as https://stackoverflow.com/questions/31446363/proper-way-to-link-static-libraries-with-dll – sandwood Oct 25 '17 at 16:36
  • Yes that’s it. And basically that’s what I do, i.e. link the .lib into my DLL project. If I hadn’t done that, the DLL project wouldn’t build anyway (due to unresolved externals). – NonoxX Oct 25 '17 at 16:59
  • Deadlock in DllMain() probably. Do use the debugger before forcing us to guess. Debug > Break All and Debug > Windows > Call stack. – Hans Passant Oct 25 '17 at 17:20

1 Answers1

0

Thanks to Hans Passant, I went to debug though the DllMain. And yes, it was a deadlock. Problem was not directly related to using a static lib into the DLL.

The in the static library, I have some static singletons that are initialized into the CRTDLLmain. I follow the double-checked locking pattern in my implementation, using c++ atomic fences (as in http://preshing.com/20130930/double-checked-locking-is-fixed-in-cpp11/). Is seems however, that it doesn't really work well with C++11 (https://github.com/weidai11/cryptopp/issues/372). I coded a quick workaround to test it and it seems so. I will then contact the lib maker to see if a fixed version is possible.

NonoxX
  • 134
  • 10