About the .pro file and dynamic libraries on QtCreator

[miguelglez]

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

TARGET = CCIV-SPS
TEMPLATE = app

SOURCES += main.cpp
mainwindow.cpp

HEADERS += mainwindow.h
MotorDeteccion.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?

[goetz]

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>
@

[miguelglez]

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?

[andre]

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

[goetz]

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:

Q_SIGNAL or Q_SIGNALS, Q_SLOT or Q_SLOTS, Q_EMIT, Q_FOREACH, Q_FOREVER

so you have to replace for example:

@
public slots:
void fancySlot();

signals:
void valueChanged(int newValue);
@

to

@
public Q_SLOTS:
void fancySlot();

Q_SIGNALS:
void valueChanged(int newValue);
@

[miguelglez]

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.

Miguel