Member Avatar for Elixir42

Hi Answerers,

Background:
I just figured out how to solve my unresolved external symbols by just dragging the project files from explorer (contained in exe's directory) and plonking them in the dll project, under thier own filter!

Original Situation:
I was getting 'unresolved external symbols' errors because I was #include-ing files that my dll needed that resided in the exe's project folder. Guessing I would figure that the .obj files would get built and the .dll would not know where they were to link to them.

My Question:
* Will this cause any problems in the future? - having two different .obj files. One for the .dll and one for the .exe?
* Is there a better way of doing this. - I tried adding the directory of the .exe's .obj files to the .dll's linker settings but it didn't work.

Thanks for your thoughts.

  • 2 Contributors
  • 2 Replies
  • 278 Views
  • 3 Hours Discussion Span
  • Latest Post Latest Post by Elixir42

Dani AI

Generated

's quick fix (copying the EXE's sources into the DLL project so the DLL builds the missing definitions) explains why the unresolved externals disappeared: the DLL now contains the definitions at link time. That also means there are effectively two compiled copies of the same code and data — one inside the EXE and one inside the DLL — which is why this works but is brittle.

Problems that commonly show up later: duplicated globals/singletons and separate static object construction/destruction in each module, subtle order-of-initialization bugs, larger binaries, and maintenance headaches. If the projects use different CRT/runtime flags or struct packing, runtime errors and heap/allocator mismatches can occur when objects or memory cross module boundaries. Passing C++ objects (virtual functions, exceptions, RTTI) between EXE and DLL also requires careful export/import semantics; simply compiling the same .cpp twice doesn’t make those semantics safe.

Safer approaches (in order of recommendation):

  • Move the shared code into a static library project (.lib). Add that project as a dependency/reference for both the EXE and the DLL so the shared code is managed and built once.
  • If a single runtime instance is required at execution, expose the shared functionality from a dedicated DLL and export a clean C++/C API (use an export/import macro).
  • As a last-resort quick hack, link the other project’s .obj into the DLL via Linker → Input, but this is fragile (build-order, path and setting mismatches) and not recommended for long-term maintenance.

Example export macro pattern:

#ifdef BUILDING_SHARED
#define API __declspec(dllexport)
#else
#define API __declspec(dllimport)
#endif

class API Foo { /* ... */ };

As hinted, the Visual Studio project system and mismatched project settings are the usual root cause of future pain. Consistent compiler/runtime flags and proper project-to-project references avoid most of these traps.

Recommended Answers

All 2 Replies

Member Avatar for rubberman

Your biggest problem in the future will be using Visual Studio. In any case, this was NOT a C++ problem. It was a Windows Visual Studio problem.

Member Avatar for Elixir42

Many thanks 'rubberman' for your swift reply. Apologies if I posted this in the wrong place.

Your biggest problem in the future will be using Visual Studio

May I ask you to elaborate on what problems I would get?

Edited by Elixir42 because: formatting
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.