About the .pro file and dynamic libraries on QtCreator

  • Hi everyone.

    I am having a bit of trouble trying to build a project on QtCreator. I am using QtCreator 2.0.1, and the version 4.7.0 of the Qt libraries for 64bits Linux.

    The question is as follows:

    I have a library which implements a class developed by me using a different development environment. This library is called "libMotorDeteccion.so". And this library needs a set of other libraries in order to work, the FLTK libraries among them. So I have the following in the .pro file:

    QT += core gui

    TEMPLATE = app

    SOURCES += main.cpp

    HEADERS += mainwindow.h
    main.h \

    FORMS += mainwindow.ui

    LIBS += -L/usr/local/cuda/lib64 -lcudart -lcutil
    LIBS += -lfltk2 -lfltk2_images -lfltk2_gl -lfltk2_glut
    LIBS += -lXft -lXext -lXi -lXinerama -lfreeimage -lboost_thread -lglut
    LIBS += -lcv -lcxcore -lhighgui
    LIBS += -lMotorDeteccion

    INCLUDEPATH += /usr/include/opencv /usr/local/include /usr/include /usr/local/include/fltk

    When I try to build the project, I get the an error originated in the file "/usr/include/qt4/QtCore/qstring.h".This file, which is part of the Qt libraries, has the following include:

    #include <string>

    Apparently, instead of loading the "normal" <string> library, there is a file on the path "/usr/local/include/fltk" also called string.h, and the compiler is trying to load that file instead of the right one. I can't avoid loading the header files of that path, because they are needed for my application.

    What can I do about it? How can I tell the compiler to load the right headers? What am I doing wrong?

  • Try to remove /usr/include from your INCLUDEPATH variable, as it's in the standard path anyways. It may be that

    Also remove /usr/local/include/fltk from the list and try to change your fltk includes:

    // old:
    #include <fltkheader.h>
    // new
    #include <fltk/fltkheader.h>

  • Hi Volker. Thank you for your quick answer.

    I am trying that approach now. I have removed the system included paths and the FLTK include path. So the INCLUDEPATH is as follows now:

    @INCLUDEPATH += /usr/include/opencv@

    (OpenCV is working fine. I don't have problems with it).

    The list of includes on my header file is as follows:

    @#include <stdio.h>
    #include <stdlib.h>
    #include <iostream>
    #include <string>

    #include <boost/thread/thread.hpp>
    #include <fltk/run.h>
    #include <fltk/Window.h>
    #include <fltk/draw.h>
    #include <fltk/Rectangle.h>
    #include <fltk/Widget.h>
    #include <fltk/events.h>

    #include "cv.h"
    #include "cxcore.h"
    #include "highgui.h"

    using namespace std;@

    I want to believe all of them are being loaded. But I am getting a new error now. It is located on the file "/usr/local/include/fltk/Widget.h". On that file, there are some declarations of functions, like the following:

    @ void add(const AssociationType&, void* data);
    void set(const AssociationType&, void* data);
    void* get(const AssociationType&) const;
    void* foreach(const AssociationType&, AssociationFunctor&) const;
    bool remove(const AssociationType&, void* data);
    bool find(const AssociationType&, void* data) const;@

    The error is in the line:

    @void* foreach(const AssociationType&, AssociationFunctor&) const;@

    I think that FLTK could be trying to use a name for a function (foreach) which is also a Qt keyword, because it appears on a different color. Is there a way to avoid this conflict?

  • You can disable Qt keywords, and use the macro versions instead.

  • Add this to your .pro file:

    CONFIG += no_keywords

    But be aware, that with this at least the following Qt keywords are not defined:

    singals, slots, emit, foreach, forever

    and you have to use the macro versions instead:


    so you have to replace for example:

    public slots:
    void fancySlot();

    void valueChanged(int newValue);


    public Q_SLOTS:
    void fancySlot();

    void valueChanged(int newValue);

  • Thank you both for your advice.

    Finally I have found a way of moving on without using the FLTK libraries, and it seems to work fine.

    See you around.


Log in to reply