build shared lib setting doesn't work under windows

[GoogleCodeExporter]

What steps will reproduce the problem?
1. configure cmake to create a shared lib using visual studio
2. build with vs11
3. a .dll is created but no .lib

What is the expected output? What do you see instead?
ceres.lib and ceres.dll should be created, but no ceres.lib is created

What version of the product are you using? On what operating system?
ceres 1.8.0, visual studio 2012 update 4 under windows 7 64 bit

Please provide any additional information below.
There are no symbols exported [no __declspec(dllexport) is used] which causes 
the lib to be skipped.  Just needs the usual microsoft declspec declarations on 
the symbols to be exported.

Original issue reported on code.google.com by Chris.Th...@gmail.com on 5 Jan 2014 at 4:23

[GoogleCodeExporter]

Original comment by sandwich...@gmail.com on 5 Jan 2014 at 4:25

[GoogleCodeExporter]

Unfortunately, Ceres as a shared library (DLL) on Windows is probably never 
going to work. This is a known issue, and it has to do with how Windows DLLs 
manage memory. Ceres expects to free memory allocated by the user (various cost 
function and loss functions), and also there are various standard library items 
(most notably vector<>) which don't work well across DLL boundaries.

With that said, I was disenchanted when I looked at this before, but if some 
brave soul were to take on the task of making Ceres-as-DLL work, I would 
happily chat about it. Since I'm not an experienced Windows developer, perhaps 
someone with more experience can step in.

I'm marking this as WONTFIX.

Original comment by mie...@gmail.com on 6 Jan 2014 at 5:14

• Changed state: WontFix

[GoogleCodeExporter]

Hi there,

Unfortunately I disagree with the WontFix. Link time code gen takes ages on 
CERES and I could really do with a DLL to speed up my Windows build.

To address the issues raised by mie...@gmail.com:

1) A shared library will work as long as the MSVC dynamic CRT is used. This 
allows a common memory allocator to be used across DLL boundaries. You should 
be able to enforce this in the cmake file by forcing/ensuring 
MSVC_USE_STATIC_CRT is false if BUILD_SHARED_LIBS is true.

2) There are problems with vector<> and friends across DLLs but, as I 
understand, these only occur if the implementations used differ between the 
DLLs. As with (1), using the dynamic runtime will avoid most of these problems. 
The other problem is making sure the headers used to build match across DLLs. 
This is a caveat that would be worth noting if CERES were ever distributed in a 
binary form but for (most) projects the standard headers used will be identical.

I hope this bug gets reopened and fixed.

(Note: at some point I may actually do it myself)

Original comment by coooo...@gmail.com on 28 May 2014 at 1:31

[GoogleCodeExporter]

Chris,

Checkout the recently released version 1.9.0 which has full support for DLL 
building.

Sameer

Original comment by sameerag...@google.com on 28 May 2014 at 1:59

• Changed state: Fixed