1

I'm exploring right now open source tools to test my QT GUI Applications. After some research I found the promising:

TUG: GUI Unit Testing library https://github.com/pedromateo/tug_qt_unit_testing_fw

Unfortunately, it is a Linux library, but I'm developing windows applications with MSVC.

But I didn't gave up and installed Cygwin. My idea was to compile TUG with Cygwin and afterwards using it together with the cygwin1.dll in my testing framework.

TUG is being compiled using qmake Project files producing normal make files.

The first step was to include the switch -D__MINGW32__ in the DEFINES section of my qmake project file. This eliminates some compilation errors.

Then I ran my qmake with:

/cygdrive/[My Windows QMake Install Path]/qmake.exe –spec cygwin-g++ tug_base_lib

Then I ran make and it compiles fine, but failed in the last step linking the object files to the libTUG.dll. It ended up with a lot of undefined references errors.

My idea is, that make tries to link MSVC Windows Libraries to my libTUG.dll resulting in an error.

Does anyone has experience in using TUG together with Windows Applications?

The corresponding section in the generated Makefile, where the linking failed was probably:

$(TARGET):  $(OBJECTS) $(SUBLIBS) $(OBJCOMP)  
    -$(DEL_FILE) $(TARGET) $(TARGET0) $(TARGET1) $(TARGET2)
    $(LINK) $(LFLAGS) -o $(TARGET) $(OBJECTS) $(LIBS) $(OBJCOMP)
    -$(QMAKE) -install ln -s $(TARGET) $(TARGET0)
    -$(QMAKE) -install ln -s $(TARGET) $(TARGET1)
    -$(QMAKE) -install ln -s $(TARGET) $(TARGET2)

where the Options where

LINK          = g++
LFLAGS        = -shared -Wl,-soname,libTUG.dll.1
LIBS          = $(SUBLIBS) -L/usr/X11R6/lib -L[Path of my Windows QT Libs] -lQt5Widgets_vc14-x64 -lQt5Gui_vc14-x64 -lQt5XmlPatterns_vc14-x64 -lQt5Network_vc14-x64 -lQt5Test_vc14-x64 -lQt5Core_vc14-x64 -lGL -lpthread 

TARGET        = libTUG.dll.1.0.0
TARGETA       = libTUG.a
TARGET0       = libTUG.dll
TARGETD       = libTUG.dll.1.0.0
TARGET1       = libTUG.dll.1
TARGET2       = libTUG.dll.1.0
Aleph0
  • 5,816
  • 4
  • 29
  • 80
  • 1
    You should most probably see the command line to the linker which causes the failure (it is normally printed to the console). Check whether the failures point to internal stuff or external libraries. For internal you can check whether all relevant object files are in the linking command line. For external, you can give the same command from hands and append it with required -l and -L options to link the missing stuff manually. – dmi Feb 24 '17 at 07:00
  • Thanks for the help. I extended my question. The path to the Windows QT Libs in the LIBS Section is correct. Also the naming of the libs is correct. (Does make search for .lib extension automatically, or is make searching for .so extension?) – Aleph0 Feb 24 '17 at 07:06
  • 1
    As per your input, your're using mingw to build. Thus I would expect *.so only (or *.a if they are linked statically), but not *.lib. – dmi Feb 24 '17 at 07:09
  • Just as a hint, explore all your error messages, perhaps you have there something besides unresolved dependency, i.e. file is not found, or wrong format, or something similar. – dmi Feb 24 '17 at 07:11
  • Yes. I ran make with -q option. That gave me a lot of debug info. But I'm not used to this unix build tools. So I'm kind of lost. My idea is that I'm not allowed to link to the windows libraries (*.lib). Am I correct with this assumption? – Aleph0 Feb 24 '17 at 07:16
  • Yes, you are correct. Both (what you're compilling and the library to link to) should be of the same type - either mingw build, or windows build. But not mixed. UPDATE: just to mention, *.lib is actually not a library (*.dll is a library) but just a description of a library. But they are still windows libraries which cannot be used in mingw build. – dmi Feb 24 '17 at 07:19
  • Actually, it would be nice if there would be no linking to static libraries after all. What about dynamic linkage to the windows qt dlls? Is this possible without changing the existing code? I guess not? – Aleph0 Feb 24 '17 at 07:35
  • You cannot link together C++ code compiled with different compilers. Only C ABIs are compatible. – n. m. could be an AI Feb 24 '17 at 08:01
  • 1
    Finally, even using mingw, you will compile a windows executable, thus it will be linked against windows dlls. However, the point is whether the linker while build process is capable to use windows dlls to link the binary. My knowlege - no, it is not capable. – dmi Feb 24 '17 at 08:01
  • Ok. Many thanks for this info. My next try is to download the QT Libraries for Cygwin and compile TUG against these. I have to pay attention, that the QT Version numbers fit. – Aleph0 Feb 24 '17 at 08:23
  • @dmi Of course it is. What kind of linker would it be otherwise? – n. m. could be an AI Feb 25 '17 at 17:45
  • Do you consider system level GUI testing tools? Python library [pywinauto](http://pywinauto.github.io/) can automate Qt GUI on Windows using MS UI Automation (backend="uia"). – Vasily Ryabov Mar 22 '17 at 08:50
  • Interesting alternative! Many thanks for this hint. A while ago I already tried the tool AutoIt, but it was lacking the specific connection to QT. I'm looking for a free alternative to Squish I think. I'll try your suggested tool, if it fits my requirements. – Aleph0 Mar 24 '17 at 07:48

0 Answers0