How to link .so files's header to other project

JacobNovitsky

Tried to link Shared.h to my other C++ App, but it does not recognize Shared.h

libshared.so libshared.so.1.0 Makefile
libshared.so.1 libshared.so.1.0.0 Shared.o
j@j-BOHB-WAX9:~/shared-Debug$

I created .so library, using below:

Qt Creator/NewProject/C++ Library/Shared Library, Qt Module = none

pro.file:

CONFIG -= qt

TEMPLATE = lib
DEFINES += SHARED_LIBRARY

CONFIG += c++17

# You can make your code fail to compile if it uses deprecated APIs.
# In order to do so, uncomment the following line.
#DEFINES += QT_DISABLE_DEPRECATED_BEFORE=0x060000    # disables all the APIs deprecated before Qt 6.0.0

SOURCES += \
    Shared.cpp

HEADERS += \
    shared_global.h \
    Shared.h

# Default rules for deployment.
unix {
    target.path = /usr/lib
}
!isEmpty(target.path): INSTALLS += target

shared_global.h

#ifndef SHARED_GLOBAL_H
#define SHARED_GLOBAL_H

#if defined(_MSC_VER) || defined(WIN64) || defined(_WIN64) || defined(__WIN64__) || defined(WIN32) \
    || defined(_WIN32) || defined(__WIN32__) || defined(__NT__)
#define Q_DECL_EXPORT __declspec(dllexport)
#define Q_DECL_IMPORT __declspec(dllimport)
#else
#define Q_DECL_EXPORT __attribute__((visibility("default")))
#define Q_DECL_IMPORT __attribute__((visibility("default")))
#endif

#if defined(SHARED_LIBRARY)
#define SHARED_EXPORT Q_DECL_EXPORT
#else
#define SHARED_EXPORT Q_DECL_IMPORT
#endif

#endif // SHARED_GLOBAL_H

Shared.h

#ifndef SHARED_H
#define SHARED_H

#include "shared_global.h"

class SHARED_EXPORT Shared
{
public:
    Shared();
    
    
    void test();
};

#endif // SHARED_H

Shared.cpp

#include "Shared.h"

Shared::Shared() {}

void Shared::test()
{
    
}

SGaist

Hi,

Where is that header located ?
Did you point your other project to it using the INCLUDEPATH variable ?

JacobNovitsky

@SGaist this header located at /home/j/shared
no, I did not point, in my thought I can point to .so file which is built object with header
If it needs to be pointed to "raw" header so I dont see reason to use .so

jsulm

@JacobNovitsky All you need to do is simply set INCLUDEPATH just like @SGaist suggested, so that the compiler can find the header file. See https://doc.qt.io/qt-6/qmake-variable-reference.html#includepath

"in my thought I can point to .so file which is built object with header" - object file has nothing to do with the header file. Object file is needed for the linker to link, header file is needed for the C/C++ preprocessor before building and linking.

JacobNovitsky

@jsulm I dont get it

I dont want my app to always rebuild any change with library I link to
that's why I do want to use .so object
if I point to header if I do any change in main app, it will rebuild linked library objects too..

Basically, I dont need to include any header, I just need to be able to use shared library's Classes and its functions and variables

jsulm

@JacobNovitsky said in How to link .so files's header to other project:

I dont want my app to always rebuild any change with library I link to
that's why I do want to use .so object
if I point to header if I do any change in main app, it will rebuild linked library objects too..

This is all just wrong.

"I dont want my app to always rebuild any change with library I link to" - it will not if you link against a shared library
"that's why I do want to use .so object" - then what do you want to do instead? Build it into your project? Then your project will be rebuild if you change the the library code
"if I point to header if I do any change in main app, it will rebuild linked library objects too" - this is just wrong as well. If you change something in your application the shared library will not be rebuild - why should it?!

JacobNovitsky

@jsulm

main_project.cpp

pro:

TEMPLATE = app
CONFIG += console c++17
CONFIG -= app_bundle
CONFIG -= qt

LIBS += -L/home/j/shared-Debug/ -lshared
INCLUDEPATH += /home/j/shared



SOURCES += \
        main.cpp

main.cpp:

#include <iostream>
#include <Shared.h>



using namespace std;

int main()
{
    cout << "Hello World!" << endl;
    Shared s;
    s.test();
    return 0;
}

all correct now?
it builds, but still I dont understand how it works

So every time I have change in header, I need rebuild it to new so ?

jsulm

@JacobNovitsky said in How to link .so files's header to other project:

So every time I have change in header, I need rebuild it to new so ?

Your library mainly consists of the Shared.cpp. If you change the library header you may need to rebuild the library (depends on the changes in the header file) and also your main project.

It is not that complex: you build the library to a so file. In the project where you want to use it you link the so (this is what LIBS is used for). But in order to use the functionality of the library in your main project (like using data types, calling functions, ...) you also need to include the header file from the library which defines the interface. This is done by adding INCLUDEPATH to tell the preprocessor where to look for header files and including the header file in your main project.

JacobNovitsky

@JacobNovitsky
I just amended function in shared program, saved cpp but did not built and main program sees previous version

jsulm

@JacobNovitsky said in How to link .so files's header to other project:

I just amended function in shared program, saved cpp but did not built and main program sees previous version

Not sure what this mean. If you mean you changed something in the shared library without rebuilding it and your main application still sees the old version then it is just logical, right? You need to rebuild the lib if you change it.

JacobNovitsky

@jsulm what is faster?
pre-compiled headers or same headers built to objects?
I used per-compiled headers and it seem to slightly speed up compilation, but I'm not sure

jsulm

@JacobNovitsky I never used pre compiled headers and as far as I know only Microsoft compiler supports them (but I could be wrong on that).

JacobNovitsky

@jsulm oh! thanks :)
any guideline how to speed compilation/execution/building time, on Ubuntu, Qt Creator 6.4.2, Qt6, gcc?
I'd like to build all neat and fully debug function to so files, it seems reasonable, but I believe I can miss something powerful

Pls advise :J

SGaist

@jsulm said in How to link .so files's header to other project:

@JacobNovitsky I never used pre compiled headers and as far as I know only Microsoft compiler supports them (but I could be wrong on that).

Pre-compiled headers are available through gcc and clang as well.

@JacobNovitsky before diving into that kind of consideration, you should first analyze what you are currently using for your application. You example library does not really warrant the use of pre-compiled headers seeing the side and number of includes it has. Take a look at the Wikipedia entry.

As for debugging, you might want to check the "release with debug info" topic. Note that you should first start with a working implementation and then pursue optimization.

jsulm

@JacobNovitsky Do you use more than one build process? With make you can do that like this: make -j NUMBER_OF_PARALLEL_BUILD_JOBS
I think QtCreator does this by default already.

JacobNovitsky

@jsulm yes, it uses "/usr/bin/make" -j8
but still it calls 30-60 seconds per build, which is way too much

jsulm

@JacobNovitsky said in How to link .so files's header to other project:

but still it calls 30-60 seconds per build

Are we talking about complete rebuild of the project or incremental builds after changing some parts of the code? How big is the project (how many lines of code)?