Installing a new library and future its compilation is always pain for me.
I've just installed simple lib: https://www.nayuki.io/page/qr-code-generator-library
It looks like all I need to run command "make" to install this lib.
The Makefile inside:
Now, I'm tring to compile my program (with #include </home/spistol/qrcodegencpp/qrcodegen.hpp>) but have no luck:
g++ qr-codegen.cpp -o qr -I /home/spistol/qrcodegencpp -L/usr/lib -lqrcodegencpp
/usr/bin/ld: cannot find -lqrcodegencpp: No such file or directory
collect2: error: ld returned 1 exit status
I've tried as well -lqrcodegen
Or like this:
g++ qr-codegen.cpp -o qr -I /home/spistol/qrcodegencpp -L/usr/lib
/usr/bin/ld: /tmp/ccyBJRsY.o: in function `generateQRCode(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)':
qr-codegen.cpp:(.text+0x30): undefined reference to `qrcodegen::QrCode::encodeText(char const*, qrcodegen::QrCode::Ecc)'
/usr/bin/ld: qr-codegen.cpp:(.text+0x3c): undefined reference to `qrcodegen::QrCode::getSize() const'
/usr/bin/ld: qr-codegen.cpp:(.text+0x71): undefined reference to `qrcodegen::QrCode::getModule(int, int) const'
collect2: error: ld returned 1 exit status
> ar -crs libqrcodegencpp.a -- qrcodegen.o
Your compiled library is a .a file, not a .so file.
> /usr/lib/x86_64-linux-gnu/libqrcodegencpp.so.1
This one looks like it was installed when you installed the up-stream version of the code. I don't know why this one doesn't resolve your symbols.
Anyway...
> g++ qr-codegen.cpp -o qr -I /home/spistol/qrcodegencpp -L/usr/lib -lqrcodegencpp
The -L path needs to be where your libqrcodegencpp.a is located.
>> /usr/lib/x86_64-linux-gnu/libqrcodegencpp.so.1
> This one looks like it was installed when you installed the up-stream version of the code.
On some distros package management has library split into "runtime" and "development" files.
The runtime is needed for running programs that have been built to use the library and contain, for example libz.so.1.2.11 and symlink libz.so.1 that points to the former. The dynamic linker does seek the libz.so.1 when one starts executable.
The development has headers (e.g. zlib.h) and symlink libz.so that points to libz.so.1.2.11. The -lz makes linker seek the libz.so.
---
The "source build" of "qrcodegencpp" shows that it does not generate .so, but static .a. The linker, rather than injecting instructions for dynamic linker, does import object code from .a into the executable. The -lqrcodegencpp should work nevertheless.