-3

I try to use multiple subprojects with dynamic linked libraries in Qt 5.x (tried with 5,13 and 5.8).

I used the Qt Creator and created one main widget project, and some simple libaries.

In main project i used the Qt creator to include another project as internal library.

I also added the dependencies in the .pro file of the top level folder

TEMPLATE = subdirs

SUBDIRS += \
    bla \
    blub \
    main \
    untitled

bla.depends = blub untitled
main.depends = bla blub

In each of th subprojects is a *_global with defines the EXPORT

#if defined(BLA_LIBRARY)
#  define BLA_EXPORT Q_DECL_EXPORT
#else
#  define BLA_EXPORT Q_DECL_IMPORT
#endif

In the mainwindow.cpp I can include the header file of another subproject, e.g.

#include "bla.h"

...
Bla *bla = new Bla();

There is also no problem to put the #include "bla.h" in mainwindow.h

I can also include e.g. blub.h in main.

My problem is to use one of the other libraries from another library.

I do the same steps.

In bla.pro

win32:CONFIG(release, debug|release): LIBS += -L$$OUT_PWD/../blub/release/ -lblub
else:win32:CONFIG(debug, debug|release): LIBS += -L$$OUT_PWD/../blub/debug/ -lblub
else:unix: LIBS += -L$$OUT_PWD/../blub/ -lblub

INCLUDEPATH += $$PWD/../blub
DEPENDPATH += $$PWD/../blub

Now as soon as i try to "#include blub.h" the following problem occurs:

If i do it in a header of bla.h an error occurs that file cannot be found. (No such file or directory)

Funnily i can include it in bla.c but then it crashes during execution as soon as an object blub is created.

Now i have a problem understanding the behaviour of Qt.

If i include blub.h in mainwindow.h I can also include blub.h in the other project in bla.h. No error, no missing file, o crash during execution. But this "fix" seem to be totally wrong.

Do i have some misunderstanding in using libraries form other libraries? Why can i only include it when including it from widget which does not use the library in first place?

Background: I wanted to use a strategy pattern and have interfaces to different strategies. The strategy should be encapsulated further and not be visible from UI at frist place.

Offler
  • 1,223
  • 1
  • 12
  • 34
  • Is this a [cyclic reference issue](https://stackoverflow.com/questions/8252910/include-and-possible-cyclical-reference)? – JHBonarius Dec 22 '20 at 20:22
  • Could you 'git push' your example code to github? Mybe somebody can help you. – Allen ZHU Dec 23 '20 at 09:40
  • @JHBonarius there is no cycle in it. main points to bla, bla to blub. – Offler Dec 24 '20 at 08:54
  • @AllenZHU Uploaded it to https://gofile.io/d/5SWe6X . It is just a demo to show what i mean with the in my opinion unneccessary blub.h. in mainwindow.h .If it is removed nothing works. – Offler Dec 24 '20 at 08:58
  • _If i do it in a header of `bla.h` an error occurs that file cannot be found_ .. this has nothing to do with what depends on who ... because .h file should be there before compiling anything ... the path in the `#include` should be correct .. you need to get this done correctly first! – Mohammad Kanan Jan 04 '21 at 13:44
  • Your dependency chain is suspicious .. since `bla.depends = blub untitled` .. then `main.depends = bla` should be sufficient .. why `main.depends = bla blub` ... ? – Mohammad Kanan Jan 04 '21 at 13:50
  • There's a lot of information here and it's unclear what your problem is exactly. https://gofile.io/d/5SWe6X has nothing pushed. Please push your full project somewhere (or put all .pro, .cpp, .h content of your MCVE in the post) so that the issue can be investigated. – jpo38 Jan 05 '21 at 20:29
  • @MohammadKanan That is apart of the question. main does not need blub. if i do not include blub in main and do not include blah.h include in main i see the error that the header file is not found in bla. – Offler Jan 06 '21 at 11:50

1 Answers1

1

In my projects, if main uses bla and bla uses blub, I have main link with both bla and bulb. Even if main does not need to have blub include path, main has to link with libblub.so. That's a situation I noticed only under Linux.

So, in main.pro, just replace

else:unix: LIBS += -L$$OUT_PWD/../bla/ -lbla

by

else:unix: LIBS += -L$$OUT_PWD/../bla/ -lbla -L$$OUT_PWD/../blub/ -lblub

no more change and it works.

I found this post referencing a similar situation. According to the answer -fPIC is supposed to fix the issue (then main could only link bla), but I checked, -fPIC is used by default in my build environment and it does not fix the issue (main has to link both bla and blub).

TheEagle
  • 5,808
  • 3
  • 11
  • 39
jpo38
  • 20,821
  • 10
  • 70
  • 151
  • Sorry. the gofile seems to expire shortly. I put a non working and working example here https://www.dropbox.com/s/r8m1yn9lyespi0x/working.zip?dl=0 https://www.dropbox.com/s/z540f5y346ctrxw/notworking.zip?dl=0 . My main problem is your conclusion. https://www.dropbox.com/s/vn3x0hi4rr0bmcf/Notworking_Why.zip?dl=0 main does not depend on blub as only bla.c uses it. In this case there is a runtime error. which disappears if main depends on blub and included blub.h – Offler Jan 06 '21 at 12:26
  • So in the last case main should use bla.h and only bla.c creates an object of type blub. From the dependencies i would have expectec that if the compiler builds bla also blub should be created. main does not use blub directly. So why is there a problem in bla.c? – Offler Jan 06 '21 at 12:34
  • @Offler: See my update please. Under Linux, I think `main` has to link with `bulb` – jpo38 Jan 06 '21 at 18:31
  • @frederic no. under windows there is only "unexpectly closed" if i try to debug "The cbd process unexpectly terminated" – Offler Jan 06 '21 at 20:53
  • @jpo oh i had the same issue with linux and windows. the actual project just to try it out was under windwos as the real project which is a bit large is under linux. I accept your answer - but to be honest i do not understand why, because in my opinion the blub should be included by blaand build together with bla and not with main. (mainly use VS where you normally would include an dll by another dll and not by main if main does not use it directly) . with win also win32:CONFIG(release, debug|release): LIBS += -L$$OUT_PWD/../blub/release/ -lblub and same with debug is needed in main project. – Offler Jan 06 '21 at 21:03
  • so i still have the question why blub is needed to build main. I thought it would be enough that bla includes it and therefore i would have expected that it would be build together with bla.o. – Offler Jan 06 '21 at 21:08
  • I agree with you, I would also expect `main` to only link with `bla`, but my experience has shown it had to link with `bulb` too. I think your question is confusing, and I'm not sure you'll get an answer because it looks related to Qt while it's actually a g++/Linux issue. I isolated your problem in a MCVE only using g++ and posted it here https://stackoverflow.com/q/65603457/3336423, let's see if someone comes with a clear reason for what we both observed. – jpo38 Jan 06 '21 at 21:17