1

I’m trying to extend an existing makefile C++ project with a Qt GUI (Qt 5.6.0 because I cannot rely on Cxx11 features). The problem is I can’t get Qt to link properly. I’d like to build a X86 application (32bit) under Win7 (x86-64). I’ve installed qt-opensource-windows-x86-mingw492-5.6.0.exe obtained from the Qt download page https://download.qt.io/archive/qt/5.6/5.6.0/. Everything compiles. However, linking yields the following error:

C:/sofit/inuit_workspace/inuit_development/tools/makefiles/inuit/MakefileCatenaISS.mk:145: recipe for target 'build/model/model.exe' failed

C:/sofit/inuit_workspace/inuit_development/tools/inuit/inuit.cpp:175: undefined reference to `_imp___ZN12QApplicationC1ERiPPci'

C:/sofit/inuit_workspace/inuit_development/tools/inuit/inuit.cpp:176: undefined reference to `_imp___ZN7QWidgetC1EPS_6QFlagsIN2Qt10WindowTypeEE'

C:/sofit/inuit_workspace/inuit_development/tools/inuit/inuit.cpp:180: undefined reference to `_imp___ZN7QWidget4showEv'

C:/sofit/inuit_workspace/inuit_development/tools/inuit/inuit.cpp:181: undefined reference to `_imp___ZN12QApplication4execEv'

C:/sofit/inuit_workspace/inuit_development/tools/inuit/inuit.cpp:307: undefined reference to `_imp___ZN12QApplicationD1Ev'

C:/sofit/inuit_workspace/inuit_development/tools/inuit/inuit.cpp:307: undefined reference to `_imp___ZN12QApplicationD1Ev'

collect2.exe: error: ld returned 1 exit status

make: *** [build/model/model.exe] Error 1

I use the following command to link:

C:\Qt\Qt5.6.0\Tools\mingw492_32\bin\g++.exe -g
-LC:\Qt\Qt5.6.0\5.6\mingw49_32\lib -lQt5Widgets -lQt5Core -lQt5Gui -lQt5Cored -lQt5Guid -lQt5Widgetsd -lqtmain -lqtmaind -o build/model/model.exe  ./build/model/objects/a.obj  ./build/model/objects/b.obj

I’ve added a bunch of libraries and various combinations. Solely using Widgets, Core, and Gui doesn’t do the trick either.

Potential causes identified in answers in related questions (see below) aimed at - Mismatch architecture lib/compiler - Missing -lQt5Widgets

However, I don’t think this applies here. Please note that I’m not using CMake or QMake (hence no .pro file or CMake files) – just plain Gnu make called within Eclipse Mars.

The source (in case of interest):

int main(int argc, char *argv[])
    QApplication app(argc, argv);
    QWidget *widget = new QWidget;
    Ui_MainWindow ui;
    widget->show();
    return app.exec();
}

And the compiler command (in case of interest):

C:\Qt\Qt5.6.0\Tools\mingw492_32\bin\g++.exe -IC:\Qt\Qt5.6.0\5.6\mingw49_32\include -IC:/my_project -Wall -g -c -DWIN32 -DUNICODE -DQT_LARGEFILE_SUPPORT -DQT_DLL -DQT_GUI_LIB -DQT_CORE_LIB -DQT_HAVE_MMX -DQT_HAVE_3DNOW -DQT_HAVE_SSE -DQT_HAVE_MMXEXT -DQT_HAVE_SSE2 -DQT_THREAD_SUPPORT   C:/my_project/1.cpp  -o C:/my_project/build/model/objects/1.obj

I've tried it with/without the Qt symbols.

Does anyone know what might be the problem?

Related:

Any help is highly appreciated.

Community
  • 1
  • 1
J. Doe
  • 13
  • 3

1 Answers1

1

There is precisely one way to get it to work without wasting a lot of time:

  1. Use qmake to generate a Makefile for your project.

  2. Ensure that it builds.

  3. Clean up the Makefile according to your needs, if desired.

You're of course free to keep regenerating the Makefile using qmake whenever you alter your sources. The major thing you'll find out is that maintaining makefiles manually is a royal pain, since you also need to maintain the dependency lists and that requires recursively scanning the files included by each translation unit. In other words, whatever Makefiles you come up with yourself will not properly rebuild the project as you modify it. Thus you'll be abandoning the benefits of the Makefile during the development process. Most manually-generated Makefiles are sorely lacking the proper dependencies of each source file - because nobody sane will manually maintain it, and once you're maintaining it automatically, you might as well use qmake or cmake to do the job.

Finally, there's no such thing as Qt that doesn't have qmake, so not using qmake is silly. If you depend on Qt, you're not making anything any easier by pretending that qmake isn't there: your project will use many other binary tools that Qt provides anyway, so giving qmake a special status just wastes your time. If your project is going to be big, you'll save lots of build time by using cmake with the Ninja generator instead, as qmake is currently stuck generating recursive Makefiles, and those lead to poor build performance.

Kuba hasn't forgotten Monica
  • 95,931
  • 16
  • 151
  • 313
  • Thanks for your reply. I completely agree with you on automatic makefile generation. The Qt gui shall be integrated into an existing system based on manually edited makefiles grown over time combining multiple build systems, i.e., giving all the control to qmake will yield considerable effort. But that's where I'll start of: somehow using Qt to get something to compile and then take it from there. – J. Doe Apr 13 '17 at 04:30
  • You don't need to give any control to qmake. Use qmake to generate the Makefile once. And then you're done. Add that Makefile to the project, and feel free to edit it to simplify it. You're then guaranteed a known working starting point. – Kuba hasn't forgotten Monica Apr 13 '17 at 14:18