I have written a websocket++ server on Ubuntu 13.10 and am trying to execute it on Linux Mint 16.
I have installed all dependencies, and the first line under main is a cout which never fires.
This is the compile command:
g++ -o Dgn Dgn.cpp ed25519-donna-master/ed25519.o
-Og -std=c++0x -I ~/Dgn -D_WEBSOCKETPP_CPP11_STL_ -D_WEBSOCKETPP_NO_CPP11_REGEX_
-lboost_regex -lboost_system -L/usr/lib -lssl -lcrypto -pthread -lpqxx
-lboost_thread -ljson_spirit -lgmp -lgmpxx
If I execute with sudo to use restricted ports, it fails immediately without error returning to the command line.
If I execute without sudo, is prints Segmentation Fault and fails immediately to the command line.
The directories in ~/Dgn are present on the new system.
I did a quick, simple test and checked to see if a basic websocket++ example could compile and execute normally, and it was successful.
Both systems are 64-bit. The only difference are the distros, but Linux Mint 16 is based upon Ubuntu 13.10, and all commands to setup were identical.
How can this be compiled so that it can execute on another system?
As a further test, I compiled it on the new system, and it works.
Is it not possible to compile on one system and run on another?
GDB
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7de58da in ?? () from /lib64/ld-linux-x86-64.so.2
The fact that cout line never fires (I assume it has << std::endl) means that the crash happens in a static object constructor. The most straightforward way to debug is to allow core dump (see man limits) and inspect the dump with gdb. So far that's all I can think of. More details will help.
Related
I have a project that compiles with GCC 32-bit. I have been trying to migrate to GCC 64-bit on my native Windows machine (not through a VM). To do this I have downloaded w64devkit from https://github.com/skeeto/w64devkit/releases. My 32-bit install comes from https://sourceforge.net/projects/mingw/.
NOTE: Both installs cannot be active at the same time. Since the 32-bit version makes it into the path before we can add the 64-bit version through the environment variables, I modify the 32-bit MinGW folder name so that when the 64-bit version of GCC tries to use as.exe and ld.exe through the path, it will find the correct versions.
I have also downloaded glm, glew, and glfw for this project, and added folders to the path to get at least the 32-bit version working.
The working command line to compile the 32-bit version is as follows:
g++ -std=c++11 -O3 -ggdb src/main.cpp -o build/main -lopengl32 -L. -I"C:\lib\glm" -I"C:\lib\glew-2.1.0-win32\include" -I"C:\lib\glfw-3.3.8.bin.WIN32\include" "C:\lib\glfw-3.3.8.bin.WIN32\lib\libglfw3dll.a" "C:\lib\glew-2.1.0-win32\lib\Release\Win32\glew32.lib"
The following command line to compile the 64-bit version also works:
g++ -std=c++11 -O0 -ggdb src/main.cpp -o build/main -lopengl32 -L. -I"C:\lib\glm" -I"C:\lib\glew-2.1.0-win32\include" -I"C:\lib\glfw-3.3.8.bin.WIN64\include" "C:\lib\glfw-3.3.8.bin.WIN64\lib-mingw-w64\libglfw3dll.a" "C:\lib\glew-2.1.0-win32\lib\Release\x64\glew32.lib"
However whenever I try to run the executables, the 32-bit version runs and the 64-bit version gives me an error in a pop-up window. "The application was unable to start correctly (0xc000007b). Click OK to close the application."
When I try to run it in one of my debuggers I get a "Error: 32-bit processes are not supported". Another debugger says "During startup program exited with code 0xc000007b".
Clearly something is going horribly wrong, but I don't know what or where.
I've been trying to locate where a segmentation fault is in a program using LLDB. I've been going to the Ubuntu shell on repl.it and compiling my code using clang++-7 -pthread -std=c++17 -o main main.cpp -g and the program compiles succesfully. Next, I run lldb main and everything's fine but as soon as I type run I get error: process launch failed: 'A' packet returned an error: 8. I've checked the docs and looked up the error but I can't seem to find anything. Thanks for any sort of help!
The full log:
~/Project$ clang++-7 -pthread -std=c++17 -o main main.cpp -g
~/Project$ lldb main
(lldb) target create "main"
Current executable set to 'main' (x86_64).
(lldb) run
error: process launch failed: 'A' packet returned an error: 8
In case you need the code it's on this Github: https://github.com/KingsleyDockerill/Wirth
For those using Docker, as mentioned here, they need to add --cap-add=SYS_PTRACE --security-opt seccomp=unconfined to their docker run command in order to use lldb.
See also this older answer.
I'm learning C++ and trying to run a simple hello world program. It compiles but it won't execute. It worked on Windows, but it won't run on Zorin OS.
I read online that the command to run it is ./test or ./test.exe.
This is what is looks like on the terminal:
$ g++ test.cpp -o test.exe
$ ./test
bash: ./test: No such file or directory
I looked at the questions similar to this, but none have helped me.
You can not expect to be able to execute the same commands on both Windows and Linux. They use different shells with different syntax and different behaviors.
Here's a typical example of compiling a file on GNU/Linux:
dir$ g++ myfile.cpp -o myfile
dir$ ./myfile
Here's a typical example of compiling the same file on Windows:
dir> g++ myfile.cpp -o myfile.exe
dir> myfile
Note in particular:
Linux doesn't use .exe or other extensions on executables, but Windows does.
Windows doesn't require specifying directory to run files in the working directory, but Bash on GNU/Linux generally does.
The only reason why the compilation command is as similar as it is is that g++ is a Unix tool ported to both platforms. Windows normally uses / instead of - for flags like -o
As commands get more complex, they start diverging even further.
I'm trying to call R from c++ on linux via RInside, I compiled R-2.15.1 from source with gcc version 4.5.3 (Debian 4.5.3-1) , I don't have sudo rights to use apt-get install. I'm using OpenBlas and a system optimized lapack. The blas and lapack libraries work fine for many scalapack applications
I installed R with
./configure --with-blas="-I/lib/OpenBLAS-v0.2.3-0/xianyi-OpenBLAS-48f075c/install/include -L/lib/OpenBLAS-v0.2.3-0/xianyi-OpenBLAS-48f075c/install/lib -lopenblas -lgfortran" --with-lapack="/usr/lib/liblapack.so -lgfortran" --enable-BLAS-shlib=yes --enable-R-shlib --enable-R-static-lib --prefix= .
which installed and runs fine,I ran make check with no errors, also all the packages (Rcpp and RInside) installed fine..
however when i use the given RInside makefile , the basic hello world example from /standard/rinside_sample0.cpp compiles! but it does not run and i get the following error
./rinside_sample0: error while loading shared libraries: libRblas.so: cannot open shared object file: No such file or directory
the file libRblas.so exists and is in the R/lib folder,
when i try to link it manually with the g++ command the make file creates or linking as follows i get a segmentation fault
/R/lib/libRblas.so ./hello_world
Segmentation fault
EDIT: heres how the example make file tries to compile an example, (which compiles fine) but won't run with the above missing libRblas.so error
g++ -I/nfs/user03/jimmie21/libs/lib64/R/include -I/nfs/user03/jimmie21/libs/lib64/R/library/Rcpp/include -I/nfs/user03/jimmie21/libs/lib64/R/library/RInside/include -g -O2 -Wall -I/usr/local/include hello_world.cpp -L/nfs/user03/jimmie21/libs/lib64/R/lib -lR -L/nfs/user03/jimmie21/libs/lib64/R/lib -lRblas -L/nfs/user03/jimmie21/libs/lib64/R/lib -lRlapack -L/nfs/user03/jimmie21/libs/lib64/R/lib -lRblas -L/nfs/user03/jimmie21/libs/lib64/R/library/Rcpp/lib -lRcpp -Wl,-rpath,/nfs/user03/jimmie21/libs/lib64/R/library/Rcpp/lib -L/nfs/user03/jimmie21/libs/lib64/R/library/RInside/lib -lRInside -Wl,-rpath,/nfs/user03/jimmie21/libs/lib64/R/library/RInside/lib -o hello_world
Couple of things:
Reproducible examples, please
You have a non-standard setup
With the script from 1), try it on a standard setting as that is how Rcpp / RInside get developed and tested (on Ubuntu / Debian)
The Rcpp test suite now contains almost 800 unit tests from around 350 unit test functions. These do not seg.fault, so the issue is at your end. Similarly, RInside has dozens of examples in the four examples/ subdirectories. This also works.
It may be as easy as tweaking the Makefile / Makevars files to make sure you get your libraries in all cases. But we can't tell as there is nothing reproducible here.
Edit If you want to link with libRblas.so then you have a completely non-standard setup as the R packages for Debian / Ubuntu as use the external BLAS. Again, not an RInside issue.
I fixed the problem by adding the R install path lib ../R/lib: to the beginning of LD_LIBRARY_PATH after that all the examples compiled and run fine
Background
Hi All,
I'm trying to use Boost::MPI, at the moment I'm just trying to run the simple first example from the tutorial. I am having trouble building/running it.
I installed boost using apt-get and installed boost_mpi & boost_serialization (1.48.0) using synaptic package manager. I installed MPICH2 using apt-get.
Even though OpenMPI was never explicitly installed it appears to be on my system, I assume this is a dependency for Boost::MPI but it appears MPICH2 and OpenMPI are treading on each other's toes.
Info
If I build using
g++ test.cpp -I/usr/include/mpich2 -L/usr/lib -lboost_mpi -lboost_serialization
then run using
mpiexec -n 2 ./a.out
It throws a bunch of errors which seem to come from OpenMPI. If I try and build by linking against the OpenMPI library using
g++ test.cpp -L/usr/lib -lboost_mpi -lboost_serialization -lmpi -I/usr/include/openmpi
I get the following errors:
/usr/bin/ld: /tmp/ccJ5ezv7.o: undefined reference to symbol 'ompi_op_set_cxx_callback'
/usr/bin/ld: note: 'ompi_op_set_cxx_callback' is defined in DSO /usr/lib/libmpi.so.0 so try adding it to the linker command line
/usr/lib/libmpi.so.0: could not read symbols: Invalid operation
If I try building using mpic++ with the following command
mpic++ test.cpp -lboost_mpi -lboost_serialization
It will not link returning a bunch of errors of the form
/usr/lib/libmpich.so: undefined reference to `MPL_trid'
so I tried linking against libmpi i.e.
mpic++ test.cpp -lboost_mpi -lboost_serialization -lmpi
This builds but on running with mpiexec yields the following errors
Fatal error in PMPI_Errhandler_set: Invalid communicator, error stack:
PMPI_Errhandler_set(118): MPI_Errhandler_set(comm=0x370500, errh=0x370be0) failed
PMPI_Errhandler_set(70).: Invalid communicator
Question
It seems to me that somehow OpenMPI and MPICH2 are getting intertwined where there really shouldn't. Does anybody know how I can build against only OpenMPI or MPICH2 then run using the correct mpiexec?
Mixing code compiled against different MPI libraries is not supported in general. If your Boost::MPI is linked against Open MPI, then you must use Open MPI for the rest of your application.
To get the mpic++ as well as the other compiler wrappers and all the header files you should install the -dev package for Open MPI. If the library has been installed as a dependency then only the run-time part will be there.