Right now I am working within Manta to load at run time scenes such as scene_0.dll, rather than compiling scene_0.cc into Manta at compile time. When that works the program I am developing that uses Manta will come next. The intention is to use Manta purely as Dlls rather than Libs, which would presumably sidestep the duplicated static variable problem I posted earlier. I think this would work because there would be no static linkage.

 

I see that either I stick __declspec(dllexport) to all classes.

 

Or, like you suggested, export the class Thread, which contains that static member threadids. Since Thread is part of the project Manta_Core and the desire is to get Manta_Core.dll, I would probably have to export all classes in this project?

 

 

---

From: Abe Stephens [mailto: " target="_blank"> ]
Sent: Thursday, October 30, 2008 12:55 PM
To: " target="_blank">
Cc: Bo Huang
Subject: Re: [Manta] CMake DLL generation and .lib linking error

 

The CMake variable is BUILD_SHARED_LIBS. Take a look at /CMakeLists.txt line:33.

 

The code doesn't contain the declspec modifiers to export/import symbols on Windows... so the default build is static. Come to think of it, could you get away with a static build of all the Manta libraries and then explicitly export a small number of symbols used by the program you are embedding Manta within?

 

Abe

 

On Oct 30, 2008, at 10:43 AM, Bo Huang wrote:

Which flags in CMake dictates creation of DLLs rather than Libs?

 

I just noticed my MSVC projects generate .libs such as Manta_Core.lib rather than Manta_Core.dll. I could manually convert them but the settings will be gone when CMake regenerates the .vcprojs.

 

Also:

 

When I manually converted the vcproj for Manta_core from generating .lib to .dll, Winnm.lib was not linked and caused linking error for the timeBeginPeriod() function. I notice that this lib is mentioned in Core/CMakelist.txt, but doesn't seem to have made a difference.

 

Thanks

 

Bo