PDA

View Full Version : Unresolved error when compiling



cgyan1
3rd July 2012, 20:51
I have a bit of a problem when compiling my application which complains with an LNK2019: unresolved error.


LNK2019: unresolved external symbol "public: void __thiscall MainWindow::showMessageBox(class QString)

Basically my application is split into modules to make it easier to add/remove features and one of those modules cannot 'see' another file.

The project structure is as follows:


Project
---- bin

---- modules
---- ---- FooModule
---- ---- ---- FooModule.h
---- ---- ---- FooModule.cpp

---- src
---- ---- MainWindow.h
---- ---- MainWindow.cpp

The compiled files from both the modules folder and src folder end up in the bin folder after a successful compilation.
FooModule is actually a separate project within the main project folder and is compiled as a shared library (i.e. dll, as I'm on Windows).
MainWindow successfully creates a new FooModule and passes itself into FooModule's constructor.
At this point FooModule knows about MainWindow's header file but can't see the implementation file as when I try to call any of MainWindow's methods from FooModule's constructor I get the unresolved error about the method I just tried to call.

I'm guessing I just haven't quite got the correct info in the .pro files:


// Project.pro

QT += core gui
TARGET = Project

TEMPLATE = subdirs
CONFIG += ordered debug

SUBDIRS += modules/FooModule \
src \



// FooModule.pro
TARGET = FooModule
TEMPLATE = lib

DEFINES += FOOMODULE_LIBRARY

SOURCES += FooModule.cpp

HEADERS += FooModule.h\
FooModule_global.h

INCLUDEPATH += ../../src

DESTDIR += ../../bin



// src.pro
QT += core gui

TARGET = Project

TEMPLATE = app

CONFIG += ordered debug

INCLUDEPATH += ../modules/FooModule

SOURCES += main.cpp\
MainWindow.cpp \

HEADERS += MainWindow.h

LIBS += -L../bin -lFooModule

DESTDIR += ../bin



Can anyone see where I have gone wrong?
Thanks

amleto
4th July 2012, 00:03
you have a circular reference. redesign/refactor to remove it.

foomodule should not be needing to know anything about users of itself.

cgyan1
4th July 2012, 09:07
Thanks, yes, I see what you mean now.
I think I've probably got my concepts muddled a little bit, this is the first time I've made and tried to use my own library.
I guess the idea of a library is a self contained unit that knows how to perform a task but has no idea how it gets used in a specific application i.e. like a database library that knows how to connect, open, query etc but it is your specific application that calls those methods.

What my thinking was to create the different modules independently from each other, passing in the Main Window to their constructors, and therefore no module has any knowledge or dependency on any other part of the program (other than the MainWindow). Each module can then look after after itself and update the MainWindow etc. This way, any module can be added or removed with ease.

I think I'm on the right lines but trying to compile each module as a dynamic library was probably the wrong approach. It would have been nice to have been able to complete a module, compile it, and then forget about it and keep the core application lightweight, also not having everything compile (all modules) when I Build or Run. Some of the Run compile times are getting a little silly now.

Thanks again for the help.