g++ ld shared library error with code::blocks - c++

There are similar topics, but I haven't managed to find my answer in them.
I am building a test console application using the code::blocks IDE. It needs to load a DVB shared library called libhdhomerun.so (from Silicon Dust) for the HD Homerun DVB tuners. The HDHR tuner library has being installed using ./configure, ..., sudo make install, ldconfig etc and it all works with their utilities (built at the same time). So - the library is there and OK.
The library installed itself into /usr/local/lib. There is actually no symlink to it as there is with other shared libraries, but then it doesn't have any version information on the end either.
When I build the code (having explicitly included /usr/local/lib/libhdhomerun.so), the ld stage fails with
"cannot find -lhdhomerun.so"
I have tried every combination of including (/usr/local/lib/) libhdhomerun.so, hdhomerun.so, libhdhomerun, hdhomerun, creating a symlink to it etc. Nothing makes any difference.
The bizarre thing is that I have udev, mysql and libdvbv5 shared libraries included in exactly the same way, and they are fine. The only one that will not link is hdhomerun.
If I run a manual verbose link step from the command line "ld -lhdhomerun.so --verbose", it does fail - because it is trying to find libhdhomerun.so.so.
Any suggestions gratefully received - but I do need to keep using code::blocks.

To link the library properly, you need to have library path defined in your environment, and use proper library name with -l flag. Library path is defined in LD_LIBRARY_PATH environment variable. For -l flag to g++, library extension should not be provided - as you already observed, so in your case it should be like this:
-lhdhomerun

Related

wxWidgets jpeg library build issue

I'm trying to build wxWidgets library into a custom path on a Fedora 27 operative system.
I achieved the wx-config file path recognition and works with the cmake execution. Also, I load libraries and include dirs based on modified wxWidgets finder cmake file that sets thewx-config custom path successfully.
But cmake does not load my wxWidgets configuration. I mean, wx_gtk2u_jpeg-3.1 builded lib could not be founded (suposed to be /usr/lib/libwx_gtk2u_jpeg-3.1.so). I need jpeg dependency from wxWidgets for my project.
I'm sure that problem is not about cmake files. However, the problem is wxWidgets compilation because cmake can found the other builded dependencies into /usr/lib/
I actually installed the libjpeg-turbo-devel package that includes the libjpeg.h needed for wxWidgets building without success of libwx_gtk2u_jpeg-3.1.so creation.
The weirdest part is that $ wx-config --libs shows the wx_gtk2u_jpeg-3.1 lib to be linked and the hint paths that it should be founded.
wxWidgets commands for building:
$ ./configure --with-libjpeg=builtin --with-libpng=builtin --with-libtiff=builtin --with-zlib=builtin --with-expat=builtin --enable-webviewwebkit=no --prefix=/opt/cpp_dependencies/2018Q1/usr'
$ make -j 4
$ make install
You can check out my cmake files, the cmake output and wxWidgets building output in order to reproducing it: https://gist.github.com/jjalvarezl/b70accae269ef56c56010bedf157c27f
You can see line 1543 of wxWidgets building output file that jpeg library is buildin, and, 1564 of same file, the make install command that installs all libwx_<lib_name>.so libraries into final /usr/lib path. Anyway, no one contains the needed library.
Please show the exact error message, as it's not clear what the actual problem is. What I can say, is that the different built-in versions of 3rd party libraries, such as libjpeg, are always static libraries, even when wxWidgets themselves are shared. I.e. you're never going to have libwx_gtk2u_jpeg-3.1.so, only .a.
I'd also strongly recommend using system versions of the 3rd party libraries under Unix systems. This means that your wxWidgets applications will get security updates from your OS vendor and you don't risk running into any incompatibilities due to using 2 different versions of the same library in your application.

Some doubts about libraries

Say, I want to write a program in C++ in Linux and I need some specific libraries. There are 2 ways of getting these libraries:
Using the command line--> apt-get install library
Downloading and extracting a .zip or .tar file from their website.
Now my questions are:
For the first method I have seen libraries being downloaded with apt-get install library and apt-get install library-dev. I know dev means development or developer, but what is the difference between installing the dev and not installing the dev? What does dev do, exactly?
For the second method, do I need to build the libraries using a compiler? Because I have seen tutorials doing it but the OS used was usually Windows, do I only have to build them on Windows and not Linux?
Also, say I can only use the 2nd method for a certain library and not the first one. After extracting, what am I supposed to do? Is there any default way of installing a library manually or is each library different?
Finally, when I use the first method where is the library installed to? Is it /usr/local/lib, /usr/lib or /usr/include? Because when I have to link to these libraries in the Linker's settings I only write their name, not the path so I assume there is already a default path for libraries to be in.
One last question: Is there any default way of installing and using libraries in general or does that depend on what I want to do, programming language, etc...?
The second method is very broad because it depends entirely on the how the project is designed including the build system used etc. Things get a little more conformant when you use a distribution's managed packages.
If you want to develop a program that uses the library you need the library-dev package that usually contains the C/C++/etc.. header files.
Many development package conform to a standard tool that helps your build system find the libraries header and binary files.
For example libcurl uses the pkg-config system so its compiler components can be found from the command line like this:
pkg-config libcurl --libs # print the library link flags
You can then add that to your Makefile (or whatever build system you use):
program:
g++ -o program program.cpp $(shell pkg-config libcurl --libs)
The $(shell pkg-config libcurl --libs) part adds the correct compiler flags to link with the library.
Not all dev packaged use pkg-config. Some come with their own tools (like mysql_config) while others let you guess and try to figure it all out for yourself (looking at you libclang).

Linking to SFML libraries without libsfml-dev

I currently have my Other Linker Options as:
Unfortunately, this means that I can only ever run the executable when libsfml-dev is installed, which is undesirable for game development. Whenever I even change the Other Linker Options or Search Directories>Linker will cause an error along the lines of:
error while loading shared libraries: libsfml-graphics.so.2.2.0: cannot open shared object file: No such file or directory. I assume this error happens because the libraries are relative, so it is completely portable.
EDIT:
I am using Code::Blocks (as you can see from the image), and I would like to know how I can link to the libraries relatively. They link fine when it is run from Code::Blocks, but when I run the executable I get the above error. My current Code::Blocks options are:
Linker Options:
(Other linker options is empty)
Search Directories:
Your first linker options would be the correct ones.
The Library libsfml-dev is only required on the compile machine.
There must also be another package which actually supplies the .so files. That one will also be required on the machine running the executable unless you package those .so files with your executable. In that case you probably need a script that sets LD_LIBRARY_PATH to the local directory containing the packaged .so files and then executes your program.

How do I build and use a dynamic library on Mac OS X?

I have a very simple question that I've been trying to figure out for the last 6 hours or so. I want to simply build a dynamic library on Mac OS X, and then build an application using that library. I've created the .dylib and compiled the test application with it, but when I run the application I get:
Joes-Mac-Pro:Desktop Joe$ ./test
dyld: Library not loaded: ./lib/simple_library.dylib
Referenced from: /Users/Joe/Desktop/./test
Reason: image not found
Trace/BPT trap: 5
I've tried making a lib folder in the executable directory and putting the dylib inside, same error. I've tried putting the dylib in the executable path itself, same error. I've tried using install_name_tool to change the path to the dylib in the executable, nothing changes, same error. I've tried building the test application with -headerpad_max_install_names and then using install_name_tool to change the path. Still nothing changes. Same error.
Is what I'm trying to do not possible with the Mac operating system? I'm new to this platform, and am used to things like this working without a hitch on Windows and GNU/Linux. Also, I'm trying to do all this with the command line. I would very much prefer to avoid XCode.
Edit: Oops, I derped. Turns out I made a typo in my install_name_tool arguments. It's working fine now.
install_name_tool is the right tool.
Try otool your_binary to see which dylib are missing.
Also be sure your binary and the linked library are build for the same architectures.
You'll need to ensure that DYLD_LIBRARY_PATH includes the directory where your library resides.
DYLD_LIBRARY_PATH
This is a colon separated list of directories that contain libraries. The dynamic linker searches these directo-
ries before it searches the default locations for libraries. It allows you to test new versions of existing
libraries.
For each library that a program uses, the dynamic linker looks for it in each directory in DYLD_LIBRARY_PATH in
turn. If it still can't find the library, it then searches DYLD_FALLBACK_FRAMEWORK_PATH and DYLD_FALL-
BACK_LIBRARY_PATH in turn.
Use the -L option to otool(1). to discover the frameworks and shared libraries that the executable is linked
against.
The various details of dynamic linking are documented in the dyld man page.

How to use SOCI C++ Database library?

I'm trying to implement soci in my program but I don't know how. I'm using C++ on Linux, on a project using netbeans. I have followed the steps in: http://soci.sourceforge.net/doc/structure.html to install it, and I tried to copy the files soci.h from /src/core and soci-mysql.h from /src/backends/mysql in my project but it gives a compilation error (these files include other soci files, but it's illogical to copy all files into the directory...). I have read the guide several time but I don't understand what I'm doing wrong. The examples only include these files.
Thanks.
Edit: I have given more information in a comment below the answer. I don't know what steps I have to follow to implement soci.
The relevant bit on that page is
When the configure script is run without parameters, the remaining part of the process will use /usr/local/include/soci as a default destination for SOCI header files and /usr/local/lib as a default destination for library files
Now /usr/local/include ought to be in your default include path (e.g. try something like gcc -c -v -x c++ /dev/null -o /dev/null to see the list your install uses) and so you can include these using
#include <soci/soci.h>
#include <soci/soci-mysql.h>
You then need to add the libraries to your link step. It looks like you'll have both static and shared versions of the libraries. You'll need to add -lsoci_core -lsoci_mysql to your link step; however if that doesn't work then you'll also need to specify /usr/local/lib as a search directory i.e. -L/usr/local/lib -lsoci_core -lsoci_mysql. (Again it's probably there already but you can see using gcc -print-search-dirs.) However, the issue then is that if you're using the shared version and /usr/local/lib isn't in your distributions library search path (see /etc/ld.so.conf and/or /etc/ld.so.conf.d/*) then it won't be able to find the shared library at runtime. You'll need to either hard-code in the path to the library with the linker switch -rpath or add /usr/local/lib to the system-wide search path as before or in your environment (variable LD_LIBRARY_PATH). I'm not sure what the best way to do this is - I'd suggest -rpath to avoid modifying the system in general, although if you're building a lot of libraries into /usr/local/lib it might make sense to add it.
I got the same doesn't load backend error on my C++ program when I execute session sql("mysql://db=...)
I found a solution (at least on my Ubuntu 11.04). Just do:
sudo -i ln -s /usr/lib/libsoci_mysql-gcc-3_0-3.0.0.so /usr/lib/libsoci_mysql.so
It seem that the SOCI library search for the file /usr/lib/libsoci_mysql.so that is not in the system, buy if you make a link to the library /usr/lib/libsoci_mysql-gcc-3_0-3.0.0.so that it's in the system it works (I think debian/ubuntu makes a file name change from the original name, but it have side effects because the SOCI library search inside for the original name).
I found the error using the bash environment variable LD_DEBUG=files and running my C++ binary.
Hope it helps.