Hello friends,

I am facing a linking problem in VC++8.0 compiler.

Suppose I have a library, say A.dll.
In this library I have a file, say x.cpp. Within this file there is a extern const variable, like

.....
__declspec( dllexport ) extern const long ERROR = 100; 
.....

Now I am trying to access that constant from another library, say B.dll.

...
extern const long ERROR;
...
void ABC::func()
{
       std::cout<<ERROR;
}
...

Now whenever I am trying to build B.dll I am getting a linking error like
ABC.obj : error LNK2019: unresolved external symbol "long const ERROR" ....

I have already linked A.lib in the makefile to generate B.dll

Pls help me to fix the problem.

Thanx,
Amit

Dani AI

Generated

A likely root cause is that the symbol never got the proper export/import decoration for MSVC, so B.dll tried to resolve a symbol that the linker did not expose from A.dll. is right to verify that ERROR is actually defined, but the usual Windows pattern is to mark the data as exported when building the DLL and as imported when consuming it. The quick, reliable fix is a small header macro so both sides use the correct attribute.

// mylib.h
#ifdef MYLIB_EXPORTS
#define MYLIB_API __declspec(dllexport)
#else
#define MYLIB_API __declspec(dllimport)
#endif

extern MYLIB_API const long ERROR;  // declaration for consumers
// mylib.cpp (build A.dll with MYLIB_EXPORTS defined)
#include "mylib.h"

MYLIB_API const long ERROR = 100;  // single definition exported by A.dll

The consumer (B.dll) simply includes the header and links against A.lib; the header causes the declaration to be treated as dllimport when building B.

Notes and cautions drawn from the thread: do not add static as suggested — static gives internal linkage and prevents exporting. The behavior on Solaris mentioned by differs because compiler/linker rules for consts vary by platform; code that happens to work on Sun Studio may need explicit dllexport/dllimport on MSVC. ’s KB reference is relevant for deeper reading on exporting data.

Simple checks when the linker still complains: confirm A.dll actually exports ERROR (use the Visual Studio command-line tool to inspect exports), make sure the correct A.lib is passed to the linker for B.dll, and rebuild both projects with matching settings. If the value is only used as a compile-time constant (no address taken), prefer an enum/static const or a wrapper function instead of exporting a data symbol across the DLL boundary.

Recommended Answers

All 4 Replies

Check and make sure that you have defined ERROR in you code.

Use static before __declspec...first lib.!...

May be it helps:

I don't test it because I never used global variables (it's true ;) ).

One more point I want to mention that it is running fine (obviously except __declspec( dllexport ) ) in Solaris environment with Sun Studio 10 compiler.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.