Manta Interactive Ray Tracer Development Mailing List

Text archives Help


[Manta] RE: Re: RE: CMake DLL generation and .lib linking error


Chronological Thread 
  • From: "Bo Huang" < >
  • To: < >
  • Subject: [Manta] RE: Re: RE: CMake DLL generation and .lib linking error
  • Date: Thu, 30 Oct 2008 17:37:24 -0400

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 [mailto:
Sent: Thursday, October 30, 2008 3:48 PM
To:
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 < "> > 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"> ]
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

 

 


Archive powered by MHonArc 2.6.16.

Top of page