how to convert a string into a directory? boost on Linux - c++

I am having trouble converting a path into a directory on Linux using a boost. below is my code, this directory exists in my folder but somehow not recognised as directory as it always print out PATH DOES NOT EXISTS
i am guessing this is a linux problem because the same code works fine on windows visual studio 2015
#include <iostream>
#include <boost/filesystem.hpp>
using namespace std;
int main()
{
boost::filesystem::path p ("/home/dj/tut");
cout <<p.generic_string()<<endl;
if (boost::filesystem::is_directory(p)) { cout << "PATH EXISTS " << endl; }else { cout << "PATH DOES NOT EXISTS" << endl; }
}
how i compile with
g++ -I /home/dj/boost_1_65_1/boost script.cpp -o test -std=c++11 -lboost_filesystem -lboost_system
and then do the following to run:
./test
with ldd test i get :
linux-vdso.so.1 => (0x00007ffc8cdb9000)
libboost_filesystem.so.1.58.0 => /usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.58.0 (0x00007fef36573000)
libboost_system.so.1.58.0 => /usr/lib/x86_64-linux-gnu/libboost_system.so.1.58.0 (0x00007fef3636f000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fef35fed000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fef35dd7000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fef35a0d000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fef357f0000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fef354e7000) /lib64/ld-linux-x86-64.so.2 (0x00007fef3678b000)

Here you specify the include file search path only, without -L to have matching libraries linked:
g++ -I /home/dj/boost_1_65_1/boost script.cpp -o test -std=c++11 -lboost_filesystem -lboost_system
If that compiles, then linker and runtime is using Ubuntu's boost libraries. Now I have no idea how this could produce the effect you get, but funny things can happen when you mix versions like this.
Try compiling something like this (fix paths as needed) to make linker search your own version of the libs:
g++ -I /home/dj/boost_1_65_1/boost script.cpp -o test -std=c++11 -L/home/dj/boost_1_65_1/boost -lboost_filesystem -lboost_system
Then to use correct library at run time, you can use this (note, single command line):
LD_LIBRARY_PATH=/home/dj/boost_1_65_1/boost ./test
Or something like that, you get the idea I hope.

Related

Is there a way to statically link the glib2 library?

Since the production device does not have a glib2 runtime environment, I need to statically link to glib2. I tried to compile and link in the following ways, but it still links libglib-2.0.so.0. I am sure that libglib-2.0.a exists on my device.
#include <glib.h>
int main(void)
{
char *test;
test = g_new0(char,1);
g_free(test);
return 0;
}
i tried build it by
gcc `pkg-config --static --libs --cflags glib-2.0` main.c -o test
ldd test
linux-vdso.so.1 (0x00007ffe9dbc8000)
libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x00007f2ee333f000)
libm.so.6 => /lib64/libm.so.6 (0x00007f2ee31fb000)
libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f2ee3183000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f2ee3162000)
libc.so.6 => /lib64/libc.so.6 (0x00007f2ee2f93000)
/lib64/ld-linux-x86-64.so.2 (0x00007f2ee3492000)
The flags that pkg-config --static gives you are library flags suited for a program that will ultimately be statically linked. Now, it's not pkg-config's job to configure your build, just to give you the flags your libraries need.
So, you need to add -s to your gcc command yourself.

C++ 11 Boost 1.65 recursive_directory_iterator giving segmentation fault error

My code below kept running into segmentation fault error and i can't seem to figure out why. Help pls~~
My goal is to read a folder and all of its subfolders to find all files ending with extension ".txt" so i am using boost's recurisve directory iterator to help achieve the task. This issue arrived suddenly as my code was running fine last week.
test.cpp:
#include <sstream>
#include <iostream>
#include "/home/dj/boost_1_65_1/boost/filesystem.hpp"
using namespace std;
int main()
{
using namespace boost::filesystem;
recursive_directory_iterator end;
for (recursive_directory_iterator it("./"); it != end; ++it)
{
std::cout << *it << endl;
}
return 0;
}
i am running on Linux and i compile my test.cpp with boost 1.65 as static :
g++ -g -I /home/dj/boost_1_65_1 test.cpp -static -static-libgcc -o delete -static-libstdc++ -std=c++11 -L/home/dj/boost_1_65_1 -lboost_filesystem -lboost_system
with gdb and some cout i found that error came from the line below.
for (recursive_directory_iterator it("./"); it != end; ++it)
somehow when i call for "recursive_directory_iterator", my system crashes giving this error
Program received signal SIGSEGV, Segmentation fault.
0x00000000004f1c8b in memcpy ()
the exact same error persists even if i reduce the code to
int main()
{
using namespace boost::filesystem;
recursive_directory_iterator it("./");
return 0;
}
The code is fine, the following is reduced for style:
Boost 1.65.1: Live On Wandbox
Boost 1.68.0: Live On Wandbox
#include <iostream>
#include <boost/filesystem.hpp>
using namespace boost::filesystem;
int main()
{
for (recursive_directory_iterator it("./"), end; it != end; ++it) {
std::cout << it->path() << std::endl;
}
}
Notes:
the code is incorrect for more recent versions of boost (*it is no longer output-streamable)
you attempt to link to a cusomt built version of the Boost libraries in /home/dj/boost_1_65_1. However, you specify the linker directory -L/home/dj/boost_1_65_1 whereas usually the libraries get built into stage/lib so you'd expect -L/home/dj/boost_1_65_1/stage/lib to find the correct version of the libraries.
Most likely you link the wrong version of the libraries (not matching the headers you use at compile-time).
To diagnose what libraries are getting linked at runtime use ldd. For example for my example:
g++ -L /home/sehe/custom/boost_1_67_0/stage/lib/ -I /home/sehe/custom/boost_1_67_0/ test.cpp -lboost_system -lboost_filesystem
You get for ldd a.out:
linux-vdso.so.1 => (0x00007fff0bfaf000)
libboost_system.so.1.67.0 => not found
libboost_filesystem.so.1.67.0 => not found
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f5e8fcb2000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f5e8fa9a000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f5e8f6d0000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f5e8f3c7000)
/lib64/ld-linux-x86-64.so.2 (0x00007f5e9003e000)
Indeed, you can see I have no libboost_system.so.1.67.0 or libboost_filesystem.so.1.67.0 in a system library directory, and it won't find them. Starting would fail:
$ ./a.out
./a.out: error while loading shared libraries: libboost_system.so.1.67.0: cannot open shared object file: No such file or directory
You can inform the runtime linker of your library path:
LD_LIBRARY_PATH=~/custom/boost_1_67_0/stage/lib ./a.out

Linking 'libstdc++' library is broken in embedded linux

I have been working on a project which will be loaded on an embedded system, has not enough memory/disk space to install a C++ compiler and compile the code, natively.
So, I need to “cross-compile” the code on my development (Host) machine to be used on the target machine (Embedded Linux).
The happening problem related to using strings and iostreams which are a feature of the C++ standard template library (STL). However, because memory is so critical in an embedded system, the standard template library (libstdc++), can not be available on target side.
I need to statistically link the standard libraries on host machine, rather than dynamically link on target side. So, in my Makefile I need to have a slightly complex modification in both compiling and linking steps in order to build my project.
I have used some parameters such as -nodefaultlibs, -static-libstdc++, and -lstdc++ in the linking step and also added -nostdinc++ to the compiler flags. Still, there exist the problem on target side; " can not load library libstdc++.so.6 "
Most of these settings I have tried did not work. Is there any solution?
-lstdc++ overrides -static-libstdc++, try linking with just -static-libstdc++.
See this for example:
$ g++ -o foo foo.cpp -static-libstdc++ -lstdc++
$ ldd foo
linux-gate.so.1 => (0x0056b000)
libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0x007ae000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0x00110000)
libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0x005dd000)
/lib/ld-linux.so.2 (0x002bc000)
libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0x0095e000)
libstdc++ is linked dynamically!
$ g++ -o foo foo.cpp -static-libstdc++
$ ldd foo
linux-gate.so.1 => (0x0097b000)
libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0x001f9000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0x0037f000)
/lib/ld-linux.so.2 (0x00199000)
now it is not.

Shared library, makefile. Library path

Im trying to link my program to the shared library. Im using a makefile to compile. It looks like this: `
make: sms_out.cpp SMSDispatch.cpp SMSDispatch.h
g++ -c -fPIC SMSDispatch.cpp -o SMSDispatch.o
g++ -shared SMSDispatch.o -o libSMSDispatch.so
` g++ sms_out.cpp -L. -lSMSDispatch -o sms_out
It works fine if I run the program in the command window with:
LD_LIBRARY_PATH="." ./sms_out
But I want to run it with just ./sms_out, can someone help me?
Tried to add export LD_LIBRARY_PATH=. to the makefile, but that didnt work, just got the error " error while loading shared libraries: libSMSDispatch.so: cannot open shared object file: No such file or directory" when I try to run the program.
Another option - provide -rpath options to linker to inform your binary where else search for dynamic objects.
g++ -Wl,-rpath=<path to .so> -o <your binary here> <cpp file name>.cpp
Add the directory where the .so file exists to LD_LIBRARY_PATH:
$ export LD_LIBRARY_PATH=/dir/containing/sharedobject
A utility you may find useful is ldd, which prints the shared library dependencies. For example:
$ ldd /bin/ls
linux-vdso.so.1 => (0x00007fff819ff000)
librt.so.1 => /lib64/librt.so.1 (0x00007fc0d3f67000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x00007fc0d3d4a000)
libacl.so.1 => /lib64/libacl.so.1 (0x00007fc0d3b42000)
libc.so.6 => /lib64/libc.so.6 (0x00007fc0d37e9000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fc0d35cd000)
/lib64/ld-linux-x86-64.so.2 (0x00007fc0d4170000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007fc0d33c9000)
libattr.so.1 => /lib64/libattr.so.1 (0x00007fc0d31c4000)
If shared objects are not locatable a string not found, or similar, is displayed instead of the path to the shared object being used.

How to call Matlab from C++ code?

I am trying to call Matlab functions from C++ code.
With Matlab it comes an example of such code at /extern/examples/eng_mat/engdemo.cpp, however I found no way to build that source code.
Here is the makefile I use:
CFLAGS = -Wall -O3
INCLUDES = -I/opt/Matlab-2009a/extern/include
LIBRARIES = -Wl,-R/opt/Matlab-2009a/bin/glnx86 -L/opt/Matlab-2009a/bin/glnx86 -lmx -lmat -leng
out : engdemo.cpp
g++ $(CFLAGS) $(INCLUDES) -static $^ $(LIBRARIES) -o out
clean :
rm -f out
(Here /opt/Matlab-2009a is my Matlab root.) I am getting a linker error like this:
/usr/bin/ld: cannot find -lmx
collect2: ld returned 1 exit status
make: *** [out] Error 1
And the question is: how can I make g++ to compile engdemo.cpp ?
Note, that the shared library exists:
$ locate libmx.so
/opt/Matlab-2009a/bin/glnx86/libmx.so
/opt/Matlab-2009a/bin/glnx86/libmx.so.csf
and
$ ldd /opt/Matlab-2009a/bin/glnx86/libmx.so
linux-gate.so.1 => (0x004b4000)
libut.so => /opt/Matlab-2009a/bin/glnx86/../../bin/glnx86/libut.so (0x0078f000)
libmwfl.so => /opt/Matlab-2009a/bin/glnx86/../../bin/glnx86/libmwfl.so (0x00110000)
libicudata.so.38 => /opt/Matlab-2009a/bin/glnx86/../../bin/glnx86/libicudata.so.38 (0xb7f82000)
libicuuc.so.38 => /opt/Matlab-2009a/bin/glnx86/../../bin/glnx86/libicuuc.so.38 (0x00bee000)
libicui18n.so.38 => /opt/Matlab-2009a/bin/glnx86/../../bin/glnx86/libicui18n.so.38 (0x001f7000)
libicuio.so.38 => /opt/Matlab-2009a/bin/glnx86/../../bin/glnx86/libicuio.so.38 (0x00e1c000)
libz.so.1 => /usr/lib/libz.so.1 (0x0098e000)
libstdc++.so.6 => /opt/Matlab-2009a/bin/glnx86/../../sys/os/glnx86/libstdc++.so.6 (0x00531000)
libm.so.6 => /lib/libm.so.6 (0x00194000)
libgcc_s.so.1 => /opt/Matlab-2009a/bin/glnx86/../../sys/os/glnx86/libgcc_s.so.1 (0x00eaa000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00900000)
libc.so.6 => /lib/libc.so.6 (0x00345000)
librt.so.1 => /lib/librt.so.1 (0x00964000)
libdl.so.2 => /lib/libdl.so.2 (0x0014e000)
libexpat.so.1 => /opt/Matlab-2009a/bin/glnx86/../../bin/glnx86/../../bin/glnx86/libexpat.so.1 (0x00152000)
libboost_thread-gcc42-mt-1_36.so.1.36.0 => /opt/Matlab-2009a/bin/glnx86/../../bin/glnx86/../../bin/glnx86/libboost_thread-gcc42-mt-1_36.so.1.36.0 (0x00fc2000)
libboost_signals-gcc42-mt-1_36.so.1.36.0 => /opt/Matlab-2009a/bin/glnx86/../../bin/glnx86/../../bin/glnx86/libboost_signals-gcc42-mt-1_36.so.1.36.0 (0x0017d000)
libboost_system-gcc42-mt-1_36.so.1.36.0 => /opt/Matlab-2009a/bin/glnx86/../../bin/glnx86/../../bin/glnx86/libboost_system-gcc42-mt-1_36.so.1.36.0 (0x00a06000)
/lib/ld-linux.so.2 (0x001db000)
So, how can I make g++ to compile engdemo.cpp ?
Assuming $MATLABROOT is the path to MATLAB:
$MATLABROOT/bin/mex -f $MATLABROOT/bin/engopts.sh engdemo.cpp
If you add the -v switch, the verbose output will show you what commands are being used to compile the engine application.
Why are you compiling with -static? From "man gcc":
-static
On systems that support dynamic linking, this prevents linking with the shared libraries. On other systems, this option has no effect.
In other words, the -static option forces the linker to only consider static libraries, meaning that it will try to find libmx.a rather than libmx.so. Since Matlab only ships with shared (dynamic) libraries, it fails.
Try removing that option & see what happens.
If that doesn't work, you may need to run libtool to help it find the .so's at runtime.
I thought I'd post something that related that might be of use to someone who stumbles upon this post in the future, on the theme of calling a Matlab function from C++.
In a tutorial posted on the Mathworks site the use of shared libraries is demonstrated for calling Matlab function(s) from a C++ file. Here, the mcc command is used to create a shared library.
Subsequently, the mbuild command is used to build the executable. However, if you have a complicated C++ code, which itself needs its own set of shared libraries for compilation, mbuild won't work. The tutorial doesn't demonstrate what needs to be done in this case. So, the purpose of my reply is to post that solution. The user C++ file is vigenere.cpp, and the shared library to be linked in this case is libvigenere.so, and this is the resultant call to g++:
g++ -o vigenere -L/usr/local/MATLAB/R2013b/runtime/glnxa64 -L. -I/usr/local/MATLAB/R2013b/extern/include/ vigenere.cpp -lmwmclmcrrt -lm -lvigenere
Some prerequisites:
The Matlab Compiler Runtime (MCR) needs to be installed. Either type mcrinstaller at the Matlab prompt, or download the appropriate installer from the Matlab site.
After doing this, make sure to set your LD_LIBRARY_PATH as per the instructions at the end of the installer.
The current working directory needs to be added to the LD_LIBRARY_PATH. In bash, I do this by export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$PWD
Note that 1&2 are also described in a readme.txt file generated by the mcc command.