LinuxQuestions.org - [SOLVED] How to compile a C++ library with a shared library?

- Programming (https://www.linuxquestions.org/questions/programming-9/)

- - How to compile a C++ library with a shared library? (https://www.linuxquestions.org/questions/programming-9/how-to-compile-a-c-library-with-a-shared-library-4175719892/)

How to compile a C++ library with a shared library?

I'm trying to compile a C++ library (libKUserFeedbackCore) which started as part of a larger project (kuserfeedback), but I don't want to download the entirety of Qt, not to mention the unrelated PHP and other crap that the CMakeLists.txt files want.

The classes I need rely solely on Qt5 Core for defining some data types.

Knowing it would fail, I ran "g++ path/to/*.cpp" and of course that complains about "#include <QMetaType>" with "fatal error: QMetaType: No such file or directory" - where QMetaType is just the first example.

I installed libqt5core5a but not sure how to point the compiler at it.

Searching found this example:

Code:

g++ -Wall -g -c $(pkg-config --cflags Qt5Gui) foo.c

Except "pkg-config --list-all" has no Qt-related results, and replacing the command substitution with /usr/lib/x84_64-linux-gnu/libQt5Core.so.5 appeared to have no effect - it outputs same errors as before.

Based on the g++ manual Link Options page, I might want "-Ldirectory -llibrary"? But since it's referring to "liblibrary.a" rather than "liblibrary.so.version" I'm not sure it's the right option. (Or maybe I need to get a libQt5Core.a file?)

In any case, I can't find a variant that changes behaviour - even specifying an invalid directory for -L simply returns the same errors as before with no indication of the option being there.

Can someone provide the correct version of this command?

Code:

g++ -Wall -shared SOMETHING /usr/lib/x84_64-linux/gnu/libQt5Core.so.5 src/provider/code/*.cpp

update: I read that I can use a colon to specify exact filename, i.e. "-l :libQt5Core.so.5" but still no luck.

With "--verbose" I can see that "-L/usr/lib/x84_64-linux-gnu" gets added to "COLLECT_GCC_OPTIONS" but isn't added to the locations in the search list - maybe I need something inside /usr/include instead of /usr/lib ?

If google helps me well, you should install this package: https://packages.debian.org/buster/qtbase5-dev

Quote:

Originally Posted by boughtonp (Post 6398483)

maybe I need something inside /usr/include instead of /usr/lib ?

That seems to have been the issue, and whilst those files would involve installing qt5base-dev which depends on a bunch more stuff, apparently at some point I already installed them for something.

And the key thing to get the compiler to actually use them is to use option "-I directory" for include.

So I did this and got different errors:

Code:

g++ -Wall -shared -I /usr/include/x84_64-linux/qt/QtCore src/provider/code/*.cpp

Because the code is inconsistently written, I had to do two includes, and also got an error about "position independent code" which meant adding "-fPIC":

Code:

g++ -Wall -shared -fPIC -I /usr/include/x84_64-linux/qt -I /usr/include/x84_64-linux/qt/QtCore src/provider/code/*.cpp

Now I'm getting errors relating to parts I've removed, so I can go resolve those, and I guess the thread is solved. (Though if there is a way to say "just use this SO file" it may be useful to know at some point.)

This should possibly be a new thread, but I'll put it here for now...

I have my modified version compiling like so:

Code:

g++ -fPIC -shared -Wall -s -std=c++11 \

  -o libKUserFeedbackCoreStub.so.1.0.0 \

  -I /usr/include/x86_64-linux-gnu/qt5 \

  -I /usr/include/x86_64-linux-gnu/qt5/QtCore \

  -I src \

  -I src/provider/core \

  src/common/*.cpp src/provider/core/*.cpp

There are no compile-time errors, however, running "nm --dynamic --demangle --defined-only" against the original libKUserFeedbackCore.so.1.0.0 generates 268 lines of symbols, whilst for my modified version it is generating 1470 lines - the significant increase appears to be due to including private members.

I haven't changed public/private/protected status, and I haven't changed the header files, so I've no idea why it is doing that.

What do I need to do to make it not do that?

Quote:

Originally Posted by boughtonp (Post 6398577)

...the original libKUserFeedbackCore.so.1.0.0 generates 268 lines of symbols, whilst for my modified version it is generating 1470 lines - the significant increase appears to be due to including private members.

I haven't changed public/private/protected status, and I haven't changed the header files, so I've no idea why it is doing that.

What do I need to do to make it not do that?

I noticed that the members that are visible in the original have KUSERFEEDBACKCORE_EXPORT in their header files, e.g: "class KUSERFEEDBACKCORE_EXPORT AbstractDataSource" - that's a macro defined in "kuserfeedbackcore_export.h" which all header files include.

On trying to understand that I found https://gcc.gnu.org/wiki/Visibility which led me to discover ack was being "helpful" and omitting generated files/dirs from my searching. :/

So I found the bit I was missing will involve setting default visibility with "-fvisibility=hidden -fvisibility-inlines-hidden" and probably some other stuff too; now I can see actual commands, this process is going to be far simpler.

Quote:

Originally Posted by boughtonp (Post 6398905)

... now I can see actual commands, this process is going to be far simpler.

That wasn't the case. :(

However, I've since found so-stub - a Perl script that will analyze an executable/library and produce a stub SO file which throws an error when it gets used.

Was easy to modify it to do nothing (instead of throwing the error), and successfully created a SO which allows Plasma to load to desktop. (Previously the desktop wasn't loading after login, with ".xsession-errors" containing an "undefined symbol" error for "/usr/bin/plasmashell".)

Now it's /usr/bin/dolphin which is giving a (different) undefined symbol error, so I'll need to modify so-stub further to accept multiple targets, and then presumably pass it all the binaries from the dozen or so packages that currently depend on the libKUserFeedbackCore1 library...

After doing the above, I now have a stub generator that produces a SO library which allows Plasma Shell, Dolphin, Akregator, Kate to launch, and none of the UserFeedback files are being created.

Those applications do crash when trying to configure their settings, whilst KMail and Sieve Editor crash immediately on launch.
(The Plasma Settings widget itself seems ok, simply displaying an error message when on the User Feedback section.)

There's enough in the .xsession-errors log and the crash reports that I should be able to figure out a solution to those crashes.

However, since this has veered away from the thread topic, I'll stop posting updates here - once I have something sufficiently working I'll post details to https://www.linuxquestions.org/questions/debian-26/remove-kuserfeedback-in-debian-bullseye-kde-plasma-4175719779