The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

static library problem

Win2K, VS2005 Exp.

I have a C++ class in a static library (not dll) which I would like to use in another project. However, I keep getting LNK2019 error (unresolved external symbol) for the class constructor when I call it in the project.

I thought, by default, everything inside a static library is available to the external world. I am not usind dllimport/dllexport.

Clearly, I am going wrong somewhere. Can anyone offer me a clue?
Tuesday, August 08, 2006
Are you including the library in the Linker settings or using a #pragma ?
Neville Franks Send private email
Wednesday, August 09, 2006
First off:

If you include the header / code file for the offending class into the project, does the error go away?

Are you including the generated library file with the linker for both release and debug modes? I can't count the number of times I forget to copy the settings over, so it's part of my pre-commit check now.
Josh McFarlane Send private email
Wednesday, August 09, 2006
I am sharing the .h file between the library and the calling application. And yes the library is included in the linker settings.

I created a dummy library and dummy console project (which means Linker>System>Subsystem is set to /SUBSYSTEM:CONSOLE). This works perfectly.

My real project has /SUBSYSTEM:WINDOWS.

I am at a loss... If you have any other ideas, please do let me know. Thanks.
Wednesday, August 09, 2006
I turned on 'verbose' mode, and I can see that the linker can find my static library. It says "Searching libraries.. " and my library name and path is in there as well.

So I don't understand why it can't find the functions. I am guessing maybe it is a name-mangling or something like that, but I don't really know.
Wednesday, August 09, 2006
This is precious!

There were some files which looked like they were included in the project (they were listed under the solution's source files), but they were not getting compiled. Hence, they were not part of the static library I was building. Gosh! Lost a day for this crap. I've never seen this happen before.

Thanks everyone!
Wednesday, August 09, 2006
One other thing to watch out for: in general, static C++ libraries only work properly if the library was compiled with the exact same compiler and the exact same compiler settings.

So you'll need a different library for debug single-threaded, debug multi-threaded, release single-threaded, release multi-threaded, etc.
Chris Tavares Send private email
Wednesday, August 09, 2006

Are you implying that the issue you mentioned does not exist for DLLs?
Wednesday, August 09, 2006
> Are you implying that the issue you mentioned does not exist for DLLs?

There are two problems:

1) Which heap manager is each module using?
2) By whom is each module's C run-time library initialized?

Re. problem #1, a DLL can use any heap manager (e.g. the heap manager from the debug version of the staticly-linked run-time libray) while the EXE is using any other heap manager (e.g. the heap manager from the release version of the dynamically-linked run-time libray), *provided that the DLL's API is designed so that the DLL doesn't allocate memory that's freed by the EXE or vice versa*.

However, problem #2 is insurmountable when it's a static LIB: because the startup code for a DLL will initialize its staticly-linked run-time library, whereas a static LIB's run-time library is assumed to have been initialized by the startup code of the EXE which contains it (which won't happen unless the EXE has the same compiler option as the LIB).

[Note: I've tested my statement about problem #1 above; my statement about probem #2 is untested, a guess.]
Christopher Wells Send private email
Thursday, August 10, 2006
I don't mind compiling different versions of the static library, but it is good to know this stuff about the DLLs.
Thank you very much.
Thursday, August 10, 2006

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz