I am trying to troubleshoot a problem I have in using the library matplot++. I need someone to teach me how to fish here instead of giving me a fish, because I'm struggling to google search the right terms to solve my problem.
My folder structure is as follows
-music_vis
|-libs
|-3rd party
|-matplot
|-matplot.h
|-other_folders_for_matplot
|-wavs
|build.sh
|main.cpp
|thread_pool.hpp
build.sh is as follows right now:
g++ -Wall -lmatplot -I /$(pwd)/libs -g -o music_vis_cpp ./music_vis_main.cpp -lstdc++fs -std=c++17 -pthread
Everything 100% works in this shell script except for something within this section:
-lmatplot -I /$(pwd)/libs
For which I get the following error:
/usr/bin/ld: cannot find -lmatplot
collect2: error: ld returned 1 exit status
Is g++ spuriously looking in my /usr/bin/ for files? Shouldn't it be looking in $(pwd)/libs?
From what I have researched, I am also supposed to have .so files, but everything under the matplot folder is .cpp or .h files. Does this mean I installed the library incorrectly into my /lib/ folder? I cloned from github and simply copied into my /lib/ folder. Without the -lmatplot flag I get the following error:
Any thoughts, resources, guidance or guidelines on how to troubleshoot these problems in the future? Thanks friends.
I followed the instructions on the repo, but piggybacking off of Compiler not finding jpeg and png libraries , I added the following flag to the cmake. This created object files for me.
-DBUILD_SHARED_LIBS=ON
I was able to build a .so file by following the build instructions included in the matplot++ .md file, but supplying an extra flag -DBUILD_SHARED_LIBS=ON
From there, under the build folder, I found a .so file somewhere in the folder tree, moved that to my /lib/ directory, and ran the following shell script:
#!/bin/bash
g++ -I /$(pwd)/libs -L /$(pwd)/libs -Wall -g -o music_vis_cpp ./music_vis_main.cpp -lstdc++fs -std=c++17 -pthread -lmatplot
And this finally built my program. However it doesn't run because shared object file doesn't exist or something.
Edit: More steps to make the program run;
Create a folder on your filesystem you want to put your .so files into and then...
export LD_LIBRARY_PATH=/home/harrison/Documents/computer/cpp_packages/shared_object_lib/
I need to run this export line every time I restart my computer, so I just add it to my build script.
So the .so file is in two places, one necessary at build time and the other necessary at run time. My binaries can be run anywhere on my computer with this method.
Related
When I compile the sources from just a directory it's OK. But if I do it from dmg image I got this:
$ make
"/Volumes/:Users:me:develop:macos_build_script:myApp:myApp_Release:myApp/myApp.app/Contents/MacOS/devkit-x86/sysroots/i386-pokysdk-darwin/usr/bin/i586-poky-linux/i586-poky-linux-g++" -std=c++11 -Wall -O2 --sysroot="/Volumes/:Users:me:develop:macos_build_script:myApp:myApp_Release:myApp/myApp.app/Contents/MacOS/devkit-x86/sysroots/core2-32-poky-linux" -c -MD main.cpp -I/Volumes/:Users:me:develop:macos_build_script:myApp:myApp_Release:myApp/myApp.app/Contents/MacOS/devkit-x86/sysroots/core2-32-poky-linux/usr/include/c++/4.9.1 -I/Volumes/:Users:me:develop:macos_build_script:myApp:myApp_Release:myApp/myApp.app/Contents/MacOS/devkit-x86/sysroots/core2-32-poky-linux/usr/include/c++/4.9.1/i586-poky-linux -o main.o
"/Volumes/:Users:me:develop:macos_build_script:myApp:myApp_Release:myApp/myApp.app/Contents/MacOS/devkit-x86/sysroots/i386-pokysdk-darwin/usr/bin/i586-poky-linux/i586-poky-linux-g++" -std=c++11 -Wall -O2 --sysroot="/Volumes/:Users:me:develop:macos_build_script:myApp:myApp_Release:myApp/myApp.app/Contents/MacOS/devkit-x86/sysroots/core2-32-poky-linux" main.o -I/Volumes/:Users:me:develop:macos_build_script:myApp:myApp_Release:myApp/myApp.app/Contents/MacOS/devkit-x86/sysroots/core2-32-poky-linux/usr/include/c++/4.9.1 -I/Volumes/:Users:me:develop:macos_build_script:myApp:myApp_Release:myApp/myApp.app/Contents/MacOS/devkit-x86/sysroots/core2-32-poky-linux/usr/include/c++/4.9.1/i586-poky-linux -lopencv_core -lopencv_highgui -lopencv_imgproc -lzmq -o aaa.bin
collect2: fatal error: cannot find 'ld'
compilation terminated.
make: *** [aaa] Error 1
After this error I unpack contents from *.dmg then run it and compilation completes successful.
Why and what I need to do to make it work from dmg?
My *.dmg contains an application and a cross-compiler. Source files for compilation are outside and created by this application. It is simple IDE.
Finaly I find out the cause of this problem. It is two bug-or-features one in macdeployqt and one in g++.
When I wrote my building script I thought it will be good to get dmg image in same directory from which I run my script. And I added a command with absolute path:
macdeployqt /Users/me/develop/macos_build_script/myApp/myApp_Release/myApp/myApp.app -dmg
The image was built and my app ran well. But. Silently macdeployqt made a name for dmg mount point from absolute path. The absolute path became a single directory name with colons instead slashes:
:Users:me:develop:macos_build_script:myApp:myApp_Release:myApp. The root of dmg did not contain this directory, it only appears when dmg image is mounted.
Then this directory with colons will be part of variables of makefile.
Cross-compilator i586-poky-linux-g++ builds an object files when paths with colons present. And I thought it's all ok with g++ if it using this coloned paths for object files. I thought the cause somwhere in other place. But I was wrong.
Backslashing of colons din't help.
In some moment I builded the dmg image by hands from a directory in which myApp.app bundle subdirectory placed with this short command:
macdeployqt myApp.app -dmg
And the problem is gone. The mount point of dmg image now is just /Volumes/myApp. I do nothing except jump to dir where myApp.app is and making the relative path.
I installed boost_1_55_0 under /usr/local/boost_1_55_0, and in my makefile I set the linking flag as:
CC = g++
CFLAGS = -I ./ -I/usr/local/boost_1_55_0 -w -std=c++11
LFLAGS = -L./ -lm -lpthread -L/usr/local/boost_1_55_0/lib -lboost_regex
I encountered nothing during compile time, but I got:
./$(exec): error while loading shared libraries:
libboost_regex.so.1.55.0: cannot open shared object file: No such file
or directory
I'm pretty sure I cleaned all old files and compiled again, I also granted access to read the files in usr/local/boost_1_55_0 by sudo chmod -R +x /usr/local/boost_1_55_0 just in case I banned access to read. However, I still got this error. I also tried to move boost_1_55_0 in /usr/lib/ but it does not work either.
I've also read this question: Compiling issue with boost and tried both solutions under this question, but neither of them works for me. Can someone figure out a different solution?
As the error implies, your executable is unable to find the shared library. Add the .so file (or all of them, if you want to be safe) that was generated by the boost build process to the same directory where your program's executable is getting generated, and try running the program again.
I manually cleaned the executable files and compiled it again, and it somehow solved my problem. I am guessing there must be some config in my system messed up so that the executable would invisibly linked to some outdated directory and cause this problem.
Good Day Everyone,
N.B - This problem has been solved - I have provided my own solution in the answer section however the solution provided by Jonathan is much shorter. Nevertheless, this was the following question I originally posted:
I am basically trying to compile a serial library (for UART communication) on Linux however I am not really sure how to correctly compile (I have mentioned what I have done so far below), any suggestions would be highly valuable. I am using the serialib library - which is composed of 2 main files (serialib.h and serialib.cpp) , you may directly view the source code of these files here (scroll all the way to the bottom and view the files in new tabs): http://serialib.free.fr/html/classserialib.html
I transferred these files (serialib.h and serialib.cpp) to my BeagleBone Black micro-controller which is running Debian (Wheezy) , g++/gcc (Debian 4.6.3-14) 4.6.3. I wrote my own program (uart.cpp is my file name) to access the functions provided by this library, this is what I wrote:
#include <iostream>
#include "serialib.h"
#ifdef __linux__
#define DEVICE_PORT "/dev/ttyO1"
#endif
int main()
{
serialib LS;
return 0;
}
So as you can see I am trying to access the 'seriallib' class. serialib.h, serialib.cpp and uart.cpp are all in the home directory. I also manually added the iostream library in serialib.cpp as I did not see it being declared in the original source code.
Now I am really unsure of how to compile such external libraries but so far I tried the following steps:
g++ -c -Wall -Werror -fPIC serialib.c to convert to PIC which gives the following error:
distcc[3142] (dcc_parse_hosts) Warning: /home/debian/.distcc/zeroconf/hosts contained no hosts; can't distribute work
distcc[3142] (dcc_zeroconf_add_hosts) CRITICAL! failed to parse host file.
distcc[3142] (dcc_build_somewhere) Warning: failed to distribute, running locally instead
g++ serialib.cpp -L /home/debian/serialib.h which gives the following error:
/usr/lib/gcc/arm-linux-gnueabihf/4.6/../../../arm-linux-gnueabihf/crt1.o: In function _start':
(.text+0x30): undefined reference tomain'
collect2: ld returned 1 exit status
distcc[3210] ERROR: compile serialib.cpp on localhost failed
As of now I am still finding out how to compile this and if I manage to work this out then I'll post my solution here too. Once again any suggestion will be highly valuable. Thank you all :) .
g++ -c -Wall -Werror -fPIC serialib.c to convert to PIC which gives the following error:
The "error" is not an error, it's a warning, telling you that your distcc setup is broken, but that it compiled locally.
That command doesn't "convert to PIC", it compiles the file serialib.c and produces a compiled object file, serialib.o
g++ serialib.cpp -L /home/debian/serialib.h
This is just nonsense. It tries to build a program from serialib.cpp and use the directory /home/debian/serialib.h (which isn't a directory!) to find libraries.
You don't need to "compile a library" you can just compile both the source files and link them together into a program. Either:
g++ -c serialib.cpp
g++ -c uart.cpp
g++ serialib.o uart.o -o uart
Or all in one command:
g++ serialib.cpp uart.cpp -o uart
You should read An Introduction to GCC to understand the commands, not just enter bogus commands without understanding them.
I have found a solution to this problem, hope this helps for all the future readers with similar problems. I have my own source code uart.cpp (Given in the question) which I want to compile, the external library is serialib that contains two main files (serialib.h and serialib.cpp), you will want to replace the following commands with respect to the files you have
Step 1: Compiling with position independent code
g++ -c -Wall -Werror -fpic serialib.cpp
Step 2: Creating a shared library
g++ -shared -o libserialib.so serialib.o , here the library is libserialib.so.
Step 3: Linking your source code with library
g++ -L /home/debian -lserialib uart.cpp -o uart
g++ -L /home/debian -Wall -o test uart.cpp -lserialib
You may save the library at a different path and you may have a different name of course. Suppose you have a library called libabc.so at the directory /home/user/myDir then the commands will be like:
g++ -L /home/user/myDir -labc your_code.cpp -o your_code
g++ -L /home/user/myDir -Wall -o test your_code.cpp -labc
test is out own program, lserialib is actually looking for libserialib.so and not serialib.o as gcc/g++ assumes all libraries start with lib and end with .so or .a and you can see the same goes for labc as it will look for libabc.so thus it is important to make sure your library name begins with lib and ends with .so or .a
Step 4: Making library available at run time
Here we provide the path where the library is actually stored, I saved it in the directory /home/debian which is why my command looks like:
export LD_LIBRARY_PATH=/home/debian:$LD_LIBRARY_PATH
if your library is saved at /path/to/file then the command will look like:
export LD_LIBRARY_PATH=/path/to/file:$LD_LIBRARY_PATH
This is to help the loader find the shared library and to view this path: echo $LD_LIBRARY_PATH and to unset this: unset LD_LIBRARY_PATH
To execute the program type either ./test or ./uart and in case of any modification to the main source code (uart.cpp in this case) , simply repeat step 3. I found the following link very useful: http://www.cprogramming.com/tutorial/shared-libraries-linux-gcc.html . Thank you to all of you who took time to read this question and especially those who gave me suggestions. If anyone has more or better solutions, feel free to post them here to assist future readers :).
When using the -l flag in a c++ makefile, I couldn't find information on what steps gcc takes in searching for that library.
For clarity of what I'm asking, I'll make up an example answer (this is completely made up):
First searches the -L flag directory
Next searches the /lib directory
Something something etc
Some extra info:
The reason I'm stuck in this is because I currently have a program that uses libconfig in the makefile like so:
g++ $(CFLAGS) -o libvldsk_config.so $(SRCDIR)/config.cpp -Wall -shared -fPIC -I$(SRCDIR) -I$(COMMON_SRCDIR) -lconfig
but this was made assuming that libconfig is installed via a package manager. I installed via source because the linux version was too old to have it in a package manager. And so I'm trying to modify my program that uses libconfig to search for the libconfig .so file in the system's /lib directory, and if it doesn't exist search for it in the current project directory.
I compiled and built the casablanca c++ rest library in my home directory where my absolute path to the necessary .so file was /home/dev/casablanca/Release/build.release/Binaries/libcpprest.so. What I wanted to do was to simply cp and past that .so file to /usr/lib/.. path to default lib search ../ so that I could easily link it with the following command:
g++ index.cpp -I/home/dev/casablanca/Release/include -lcpprest -std=c++11
which compiled fine, but when I ran ./a.out I got the typical runtime error:
couldn't load shared library: libcpprest.so
even after adding the default path of libcpprest.so to LD_LIBRARY_PATH.
However everything worked just fine if I linked the directory where the binary was originally created at:
// ./a.out runs just fine
g++ index.cpp -I/home/dev/casablanca/Release/include \
-L/home/dev/casablanca/Release/build.release/Binaries -lcpprest -std=c++11
I'm guessing that the reason why I can't simply move the .so object where I want to add it is somehow the compiler keeps references to it somehow. How can I install this binary in a different path?
I did compile casablanca on my linux debian ( https://git01.codeplex.com/casablanca ) with procedure https://casablanca.codeplex.com/wikipage?title=Setup%20and%20Build%20on%20Linux&referringTitle=Documentation
after compilation i get a libcpprest.so with that (objdump) :
SONAME libcpprest.so.2.2
so you might want to copy libcpprest.so.2.2 to /usr/lib/libcpprest.so.2.2
or use ldconfig tool to do so.
looking into Release/build.release/Binaries you will find :
libcpprest.so -> libcpprest.so.2.2
libcpprest.so.2.2
then libcpprest.so is just a link, real library is libcpprest.so.2.2
The section you are referring to is tuned by the rpath switch:
g++ -Wl,-rpath,/path/to/lib ...