Issue 85 in ctemplate: when static link ctemplate, vc auto create test.lib test.exp with test.exe

[ctem...@googlecode.com]

Status: New
Owner: ----
Labels: Type-Defect Priority-Medium

New issue 85 by W.Wilber...@gmail.com: when static link ctemplate, vc
auto create test.lib test.exp with test.exe
http://code.google.com/p/ctemplate/issues/detail?id=85

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.

Attachments:
Makefile 1.1 KB
template_cache.h.diff 526 bytes

[ctem...@googlecode.com]

Comment #1 on issue 85 by olafv...@gmail.com: when static link ctemplate,

vc auto create test.lib test.exp with test.exe
http://code.google.com/p/ctemplate/issues/detail?id=85

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

[ctem...@googlecode.com]

Comment #2 on issue 85 by W.Wilber...@gmail.com: when static link

ctemplate, vc auto create test.lib test.exp with test.exe
http://code.google.com/p/ctemplate/issues/detail?id=85

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

[ctem...@googlecode.com]

Comment #3 on issue 85 by olafv...@gmail.com: when static link ctemplate,

vc auto create test.lib test.exp with test.exe
http://code.google.com/p/ctemplate/issues/detail?id=85

Another macro might be ok if necessary.

[ctem...@googlecode.com]

Comment #4 on issue 85 by csilv...@gmail.com: when static link ctemplate,

vc auto create test.lib test.exp with test.exe
http://code.google.com/p/ctemplate/issues/detail?id=85

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!

[ctem...@googlecode.com]

Comment #5 on issue 85 by olafv...@gmail.com: when static link ctemplate,

vc auto create test.lib test.exp with test.exe
http://code.google.com/p/ctemplate/issues/detail?id=85

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

[ctem...@googlecode.com]

Comment #6 on issue 85 by W.Wilber...@gmail.com: when static link

ctemplate, vc auto create test.lib test.exp with test.exe
http://code.google.com/p/ctemplate/issues/detail?id=85

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.

[ctem...@googlecode.com]

Comment #7 on issue 85 by olafv...@gmail.com: when static link ctemplate,

vc auto create test.lib test.exp with test.exe
http://code.google.com/p/ctemplate/issues/detail?id=85

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

[ctem...@googlecode.com]

Comment #8 on issue 85 by W.Wilber...@gmail.com: when static link

ctemplate, vc auto create test.lib test.exp with test.exe
http://code.google.com/p/ctemplate/issues/detail?id=85

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:)

[ctem...@googlecode.com]

Comment #9 on issue 85 by W.Wilber...@gmail.com: when static link

ctemplate, vc auto create test.lib test.exp with test.exe
http://code.google.com/p/ctemplate/issues/detail?id=85

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

[ctem...@googlecode.com]

Comment #10 on issue 85 by rockdrea...@gmail.com: when static link

ctemplate, vc auto create test.lib test.exp with test.exe
http://code.google.com/p/ctemplate/issues/detail?id=85

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

[ctem...@googlecode.com]

Comment #11 on issue 85 by olafv...@gmail.com: when static link

ctemplate, vc auto create test.lib test.exp with test.exe
http://code.google.com/p/ctemplate/issues/detail?id=85

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.