cannot find library...

[Anonymous_Banned275]

I wound like to continue this thread to point out some of the difficulty adding a library to sudir.

As requested ,, here is a copy of .pro AFTER " Add library.. ' option. The code complies and runs.

unix:!macx: LIBS += -L$$PWD/../BT_Utility_Library/ -lBT_Utility_Library

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

unix:!macx: LIBS += -L$$OUT_PWD/../BT_Utility_Library/ -lBT_Utility_Library

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

unix:!macx: LIBS += -L$$OUT_PWD/../Bluetoothctl_Dialog/ -lBluetoothctl_Dialog

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

It seems (works) that the library has to be added as "internal " - as the option is clearly given in "add library " dialog.

Then "compiled" and BEFORE run added AGAIN as external library - ".so " and recompiled and then it will link and run...

The first "compile" builds the .so in different folder-
AND it actually build a folder with " debug" in the name - it brings up a question

WHAT is this ",,,, debug " folder ?
What does it do ?

It is clearly NOT given as option in Linux !

Second subject for discussion
it is really nice QT GUI "build / create /compile" hides the actual compiler / linker options , BUT
it would be nice to have an option to show all these "low level " options . I assume there is some kind of configuration file which contains the "low level " commands.

[Anonymous_Banned275]

@AnneRanch Here is an example of "...debug" folder / directory created by compiler :

That basically stops the linker from finding the .so library.

This is just an example...

[Axel Spoerl]

@AnneRanch
I am sure, we can solve your problem if you post all of what I asked you here. Is there a specific reason, why you ignore that request?

[Anonymous_Banned275]

@Axel-Spoerl Yes, apparently you cannot participate in discussion and include what others have posted...
the .pro path has nothing to do with the issue
the compiler output shows WHERE the .so files are
hence location of .so files is already known
the compiler DOES not posts #include errors
( the path for #include is not an issue )
The issue is
why using internal file option creates/ builds the .so files (good) in new , QT created location (BAD ) .

Somebody mentioned that " windows debug ..." option does not apply in Linux BUT it sure looks as some other (IDE unknown ) option is creating NEW folder which surprisingly contains "debug" in name ,,,
Lets work on this together and try to go forward with what we know... Cheers

[Axel Spoerl]

Here is what we know:
The compiler creates library A:
libTEST_LIBRARY_SUB.so.1.0.0 libTEST_LIBRARY_SUB.so
in /mnt/usb-**Seagate_Expansion_NA833BDC-0:0-part4/BT__PROGRAMS/build-TEST_SUBDIRS-Qt_5_15_2_gcc_64-Debug/TEST_LIBRARY_SUB

I creates two symlinks to the library:

ln -s libTEST_LIBRARY_SUB.so.1.0.0 libTEST_LIBRARY_SUB.so.1
ln -s libTEST_LIBRARY_SUB.so.1.0.0 libTEST_LIBRARY_SUB.so.1.0

We also know, that the linker is instructed to find library B: libBT_Utility.so.1
in /mnt/usb-Seagate_Expansion_NA833BDC-0:0-part4/BT__PROGRAMS/UTILITY_DEBUG/untitled/untitled

These are two different libraries in two different paths.
In the part that you have elected to share with us, the linker can't find library A.
In the other part you have elected to share with us, the compiler successfully produces library B.
Two separate things, completely unrelated.
@JonB has already pointed at this discrepancy.

On a side note:
The first path contains two asterisks between usb-and Seagate, which is a potential error source.

What you know, but we don’t:

• The very specific linker instruction makes me believe, that library B may actually exist. Maybe it's created in another compile step. If it was my problem on my computer, I'd search for the library on the file system.

• The linker instruction must be in one (or more) of your .profiles. If it was my problem on my computer, I'd inspect them and share them with an expert.

Lets work on this together and try to go forward with what we know.

Sometimes we are baffled with a problem, that is not rooted where we firmly believe it is. Then we need the help of others to look into places, where we haven't looked before - because we were biased by our opinion to look only where we expect the issue to reside. If I may be frank: It is kind of a pattern in your posts, that you refuse requests to shed light to unexpected corners. Some of them might seem overly formal. Some of them might turn out to be useless. They all have one single intention: Understand a problem and solve it.

@AnneRanch said in cannot find library...:

Yes, apparently you cannot participate in discussion and include what others have posted...

Breathe. Smile :-)

[Anonymous_Banned275]

@Axel-Spoerl Thanks, nice summary what was already discussed ..
The ** is part of this posting software BOLD HIGHLIGHT, sorry ...

Here is working result of adding libraries to one .pro of the subpro structure -
NONE of them have "debug" added.

It is pretty useless without knowing the absolute path to the main subproject .pro

INCLUDEPATH += $$PWD/../../../../../../../../mnt/A_BT_DEC10/BT__PROGRAMS/BT_FT857_CAT_DEV13_V1/BT_LIBRARY/BT_Utility_Library
DEPENDPATH += $$PWD/../../../../../../../../mnt/A_BT_DEC10/BT__PROGRAMS/BT_FT857_CAT_DEV13_V1/BT_LIBRARY/BT_Utility_Library

unix:!macx: LIBS += -L$$OUT_PWD/../../../../../../../../mnt/A_BT_DEC10/BT__PROGRAMS/build-BT_FT857_CAT_DEV13_V1-Qt_5_15_2_gcc_64-Debug/BT_LIBRARY/BT_Utility_Library/ -lBT_Utility_Library

INCLUDEPATH += $$PWD/../../../../../../../../mnt/A_BT_DEC10/BT__PROGRAMS/BT_FT857_CAT_DEV13_V1_LIBRARY/BT_LIBRARY/Bluetoothctl_Dialog
DEPENDPATH += $$PWD/../../../../../../../../mnt/A_BT_DEC10/BT__PROGRAMS/BT_FT857_CAT_DEV13_V1_LIBRARY/BT_LIBRARY/Bluetoothctl_Dialog

unix:!macx: LIBS += -L$$OUT_PWD/../../../../../../../../mnt/A_BT_DEC10/BT__PROGRAMS/build-BT_FT857_CAT_DEV13_V1-Qt_5_15_2_gcc_64-Debug/BT_LIBRARY/Bluetoothctl_Dialog/ -lBluetoothctl_Dialog

INCLUDEPATH += $$PWD/../../../../../../../../mnt/A_BT_DEC10/BT__PROGRAMS/BT_FT857_CAT_DEV13_V1/BT_LIBRARY/Bluetoothctl_Dialog
DEPENDPATH += $$PWD/../../../../../../../../mnt/A_BT_DEC10/BT__PROGRAMS/BT_FT857_CAT_DEV13_V1/BT_LIBRARY/Bluetoothctl_Dialog

unix:!macx: LIBS += -L$$OUT_PWD/../../../../../../../../mnt/A_BT_DEC10/BT__PROGRAMS/BT_FT857_CAT_DEV13_V1/BT_MS_LIBRARY/ -lBT_MS_LIBRARY

INCLUDEPATH += $$PWD/../../../../../../../../mnt/A_BT_DEC10/BT__PROGRAMS/BT_FT857_CAT_DEV13_V1/BT_MS_LIBRARY
DEPENDPATH += $$PWD/../../../../../../../../mnt/A_BT_DEC10/BT__PROGRAMS/BT_FT857_CAT_DEV13_V1/BT_MS_LIBRARY

[Anonymous_Banned275]

@AnneRanch Just for info
if I add
"internal" library with both "Linux" and "windows " options - it add this to .pro

win32:CONFIG(release, debug|release): LIBS += -L$$OUT_PWD/BT_LIBRARY/BT_Utility_Library/release/ -lBT_Utility_Library
else:win32:CONFIG(debug, debug|release): LIBS += -L$$OUT_PWD/BT_LIBRARY/BT_Utility_Library/debug/ -lBT_Utility_Library
else:unix:!macx: LIBS += -L$$OUT_PWD/BT_LIBRARY/BT_Utility_Library/ -lBT_Utility_Library

**this  is also added - Linux add** 

INCLUDEPATH += $$PWD/BT_LIBRARY/BT_Utility_Library
DEPENDPATH += $$PWD/BT_LIBRARY/BT_Utility_Library

add I get this "else" error when "build" HENCE I CANNOT Accidentally use "windows" options , not without consequence...

[Axel Spoerl]

@AnneRanch said in cannot find library...:

It is pretty useless

Yes. Because you posted the wrong file.
We need the .pro file containing libBT_Utility.so.1 in a line starting with LIBS +=

Have you located libBT_Utility.so.1 in your file system?

[Anonymous_Banned275]

@Axel-Spoerl Sorry . I got involved in another issue.

There is no .so info when "add library" is used
HERE
( I believe INCLUDEPATH can be printed but I forgot how )

unix:!macx: LIBS += -L$$OUT_PWD/../MS_BASE_CLASS/ -lMS_BASE_CLASS

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

Yes. Because you posted the wrong file.
We need the .pro file containing libBT_Utility.so.1 in a line starting with LIBS +=

Have you located libBT_Utility.so.1 in your file system?

[Axel Spoerl]

@AnneRanch
Hi Anne,

hm. And could you locate any of the libraries on your drive?
(libBT_Utility.so.1or libBT_Utility.so.1)

I am insisting on that question for a number of reasons.

• Compilation and linking does quite some heavy lifting on the file system. Building on an external drive puts a bottle neck into the game. It really would be good to know, if everything the compiler says it has done is really done.
• Some of your file paths contain dates (e.g. DEC10). Such paths might confuse the linker as well: Something expected in the DEC10tree, may have been built on another day and be in another tree, e.g. NOV17.
• Maybe you have turned an existing project into a SUBDIRS project. That is likely to change a lot of relative paths.

Brgds
Axel