So, essentially Manta related happens in the dll. The main exe would call the dll and doesn’t know about Manta at all. In this fashion, there is only one memory space. I guess this is indicative that my mentioned method of converting all manta libs to dll would work to prevent static variables from being duplicated. That is, even if scene_0.dll refers to the static variables defined in manta_core.dll, no additional copies of these statics would be created in scene_0.dll.

 

I also observed that Core/CMakelist.txt does not include AtomicCounter_default.cc or AtomicCounter_x86.cc. Hence I get linking errors when other components such as Manta_interface refers to AtomicCounter. Previously when I compiled these components as libs rather than dlls I did not encounter this.

 

If I include either source into CMakelist.txt, the compilation fails because other needed manta headers are not included. Should I manually fix either source? I may encounter more such occurrences.

 

Thanks

 

Bo.

 

---

From: James Bigler [ " style="color: blue; text-decoration: underline; ">mailto: ] 
Sent: Thursday, October 30, 2008 3:48 PM
To:  " style="color: blue; text-decoration: underline; ">
Subject: [Manta] Re: RE: CMake DLL generation and .lib linking error

 

When I was working on a plugin that used Manta, I built the Manta libraries as static, then linked them all into the final plugin (which was a dll).  This way I could get access to all the classes without having to export any Manta things.  I didn't attemp to load any of the scene files, because the plugin generated the scene geometry I needed.  This worked on Mac, Linux and Windows.

James

On Thu, Oct 30, 2008 at 1:28 PM, Bo Huang < " style="color: blue; text-decoration: underline; "> > wrote:

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" style="color: blue; text-decoration: underline; "> ] 
Sent: Thursday, October 30, 2008 12:55 PM
To:  " target="_blank" style="color: blue; text-decoration: underline; ">
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