when static link ctemplate, vc auto create test.lib test.exp with test.exe

[GoogleCodeExporter]

I want to static link ctemplate, so I write a Makefile(See attachment).

My test file is name test.cpp

I compile it: cl $(CFLAGS) test.cpp
then link:link test.obj libctemplate.lib

The link.exe create:test.exe test.exp test.lib

After search header file, I found template_cache.h have __declspec(dll...).

I modify the header, the issue gone.

Ctemplate version is ctemplate-2.0

Thanks to Issue 67.

Original issue reported on code.google.com by W.Wilberforce.Jr@gmail.com on 1 Feb 2012 at 3:57

Attachments:

• Makefile
• template_cache.h.diff

[GoogleCodeExporter]

"__declspec(dllexport)" was added to avoid a warning when using the DLL, so you 
can't just remove it.

Original comment by olafvdspek on 1 Feb 2012 at 9:16

[GoogleCodeExporter]

But it is posssible to use *.def export function name? Or add an other define 
MACRO? Such as "CTEMPLATE_STATIC".

Original comment by W.Wilberforce.Jr@gmail.com on 1 Feb 2012 at 11:05

[GoogleCodeExporter]

Another macro might be ok if necessary.

Original comment by olafvdspek on 1 Feb 2012 at 12:24

[GoogleCodeExporter]

Ugh, sorry for that problem.  Olaf is right that I added these to silence a 
warning, probably based on advice in the MSDN.  This dllimport/export stuff is 
all a black art to me.

Olaf's the one in charge these days, so he gets to decide on the best fix!

Original comment by csilv...@gmail.com on 1 Feb 2012 at 6:40

[GoogleCodeExporter]

Just realized I've hit this issue too, didn't know it was due to ctemplate.

Original comment by olafvdspek on 1 Feb 2012 at 6:49

[GoogleCodeExporter]

I know two way to generate dll *.lib (c dll not c++ dll). 
 1th: Using lib.exe with *.def file to create *.lib.
 2nd: Using __declspec(dllexport) auto create *.lib.

And I only know __declspec(dllexport) to export c++ class.

Original comment by W.Wilberforce.Jr@gmail.com on 2 Feb 2012 at 3:07

[GoogleCodeExporter]

Just wondering, who is actually using the DLL? Until Windows gets package 
management, I prefer static linking.

Original comment by olafvdspek on 2 Feb 2012 at 3:10

[GoogleCodeExporter]

Static link cost much time for big library(such like boost,ACE,sqlite3,etc...).
I always using dll for debug, and static link for release. 
I don't like dll because there still have chance two dll have same name:(
And many user I know always like one executive file. They don't like setup:)

Original comment by W.Wilberforce.Jr@gmail.com on 2 Feb 2012 at 3:27

[GoogleCodeExporter]

Maybe better to use *.manifest to find the right dll.

Original comment by W.Wilberforce.Jr@gmail.com on 2 Feb 2012 at 3:29

[GoogleCodeExporter]

The main issue isn't that there's no package management, it's that the 
ctemplate library has an interface based on std::*.

Trying to export that from a dll in a way that works across versions of visual 
studio and mingw is practically hopeless as you run into all sorts of problems 
regarding allocation, internal data alignment etc.
The compiler is correct when it issues a warning as there's no guarantee that 
the dll you're creating will be used by an executable that has the same idea of 
what an std::map or std::string is, let alone how to destroy it!

The following link clearly illustrates the issue at hand... 
http://lmgtfy.com/?q=std%3A%3Astring+dll+boundary

in short, providing a precompiled static library or dll is unrealistic unless 
we 
- prepare different versions for every 
compiler/c-runtime/{release|debug}/thread-type permutation
or
- make the ctemplate public api [char *]-based

Original comment by rockdrea...@gmail.com on 4 Jun 2012 at 5:15

[GoogleCodeExporter]

My assumption was that package management would take care of these variants. 
Not using std::string in the ABI might be an option.
The simple 'solution' might be to drop support for DLLs.

Original comment by olafvdspek on 11 Jun 2012 at 2:51