I have this program which uses Boost::Asio for sockets. I pretty much altered some code from the Boost examples. The program compiles and runs just like it should on Windows in VS. However, when I compile the program on Linux and run it, I get a Segmentation fault.
I posted the code here
The command I use to compile it is this:
c++ -I/appl/htopopt/Linux_x86_64/NTL-5.4.2/include
-I/appl/htopopt/Linux_x86_64/boost_1_43_0/include
mpqs.cpp mpqs_polynomial.cpp mpqs_host.cpp -o mpqs_host
-L/appl/htopopt/Linux_x86_64/NTL-5.4.2/lib -lntl
-L/appl/htopopt/Linux_x86_64/gmp-4.2.1/lib -lgmp -lm
-L/appl/htopopt/Linux_x86_64/boost_1_43_0/lib -lboost_system
-lboost_thread -static -lpthread
By commenting out code, I have found out that I get the Segmentation fault due to the following line:
boost::asio::io_service io_service;
Can anyone provide any assistance, as to what may be the problem (and the solution)?
Thanks!
Edit: I tried changing the program to a minimal example, using no other libraries or headers, just boost/asio.hpp:
#define DEBUG 0
#include <boost/asio.hpp>
int main(int argc, char* argv[]) {
boost::asio::io_service io_service;
return 0;
}
I also removed other library inclusions and linking on compilation, however this minimal example still gives me a segmentation fault.
From the GCC online documentation of the -static option:
On systems that support dynamic linking, this prevents linking with the shared libraries.
Boost can support static-only linkage but only if it was configured that way when the OS Package maintainer built it. Are you absolutely certain you should be using this flag? If not, try recompiling without the flag and see if that doesn't take care of the problem.
Related
I am currently trying to write a small program using FMOD audio libraries but am having trouble understanding how to link them.
I have a small program that looks as follows
#include "/home/me/fmod_test/api/lowlevel/inc/fmod.h"
#include "/home/me/fmod_test/api/lowlevel/inc/fmod.hpp"
#include "/home/me/fmod_test/api/lowlevel/inc/fmod_errors.h"
#include <iostream>
using namespace std;
int main()
{
FMOD::System *system;
FMOD::Sound *sound1;
FMOD::System_Create(&system); // create an instance of the game engine
}
But when I attempt to compile using
g++ -L/home/me/fmod_test/api/lowlevel/lib/x86_64 -lfmod -lfmodL test.cpp -o test
I get an error like this
In function `FMOD::System_Create(FMOD::System**)':
test.cpp:(.text._ZN4FMOD13System_CreateEPPNS_6SystemE[_ZN4FMOD13System_CreateEPPNS_6SystemE]+0x14): undefined reference to `FMOD_System_Create'
I have included screenshots to show that these libraries and headers do actually exist in my system
Interestingly enough, if I comment out the System_Create call the FMOD::System and Sound initializations still work fine.
Am I linking incorrectly, I cant figure out why this wouldnt be working (and yes I am on x86_64 architecture as per the output of uname -a)
g++ -L/home/me/fmod_test/api/lowlevel/lib/x86_64 -lfmod -lfmodL test.cpp -o test
This command line is backwards. As explained in this answer, libraries must follow sources and object files on command line (the answer says that the order doesn't matter for shared libraries, but that part of the answer is wrong (for at least some linkers)). Try:
g++ -L/home/me/fmod_test/api/lowlevel/lib/x86_64 test.cpp -o test -lfmod -lfmodL
I am building a shared library which uses Boost.thread internally. As a result, Boost.system is also used since Boost.thread depends on that. My shared library exports a C interface, so I want to hide all my internal exception handling and thread usage etc from the end user. It is supposed to be a black box so to speak. However, when I link with a client application, while the program runs fine - as soon as it is time to stop the processing by invoking a library function I get:
terminate called after throwing an instance of 'boost::thread_interrupted'
I catch this exception internally in the library, so I have no idea why it is not actually being caught. The end user's program is not meant to know about or handle Boost exceptions in any way. When building the shared library, I use static linking for both Boost.thread and Boost.system so the outside world is never meant to see them. I am on GCC 4.7 on Ubuntu 12. On Windows, I have no such problems (neither with MSVC or MinGw).
(EDIT)
I am editing the question to show a minimalistic example that reproduces the problem, as per the requests in the comments.
Here first is the code for testlib.cpp and testlib.h.
testlib.cpp:
#include <boost/thread/thread.hpp>
void thread_func()
{
while(1)
{
boost::this_thread::interruption_point();
}
}
void do_processing()
{
// Start a thread that will execute the function above.
boost::thread worker(thread_func);
// We assume the thread started properly for the purposes of this example.
// Now let's interrupt the thread.
worker.interrupt();
// And now let's wait for it to finish.
worker.join();
}
And now testlib.h:
#ifndef TESTLIB_H
#define TESTLIB_H
void do_processing();
#endif
I build this into a shared library with the following command:
g++ -static-libgcc -static -s -DNDEBUG -I /usr/boost_1_54_0 -L /usr/boost_1_54_0/stage/lib -Wall -shared -fPIC -o libtestlib.so testlib.cpp -lboost_thread -lboost_system -lpthread -O3
Then, I have the code for a trivial client program which looks as follows:
#include "testlib.h"
#include <cstdio>
int main()
{
do_processing();
printf("Execution completed properly.\n");
return 0;
}
I build the client as follows:
g++ -DNDEBUG -I /usr/boost_1_54_0 -L ./ -Wall -o client client.cpp -ltestlib -O3
When I run the client, I get:
terminate called after throwing an instance of 'boost::thread_interrupted'
Aborted (core dumped)
I am not explicitly catching the thread interruption exception, but according to the Boost documentation Boost.thread does that and terminates the given thread only. I tried explicitly catching the exception from within the thread_func function, but that made no difference.
(End OF EDIT)
(EDIT 2)
It is worth noting that even with -fexceptions turned on, the problem still persists. Also, I tried to throw and catch an exception that is defined in the same translation unit as the code that catches and throws it, with no improvement. In short, all exceptions appear to remain uncaught in the shared library even though I definitely have catch handlers for them. When I compile the client file and the testlib file as part of a single program, that is to say without making testlib into a shared library, everything works as expected.
(End OF EDIT 2)
Any tips?
I finally figured it out. The -static flag should never be specified when -shared is specified. My belief was that it merely told the linker to prefer static versions of libraries that it links, but instead it makes the generated dynamic library unsuitable for dynamic linking which is a bit ironic. But there it is. Removing -static solved all my problems, and I am able to link Boost statically just fine inside my dynamic library which handles exceptions perfectly.
Maybe this?
If you have a library L which throws E, then both L and the
application A MUST be linked against X, the library containing the
definition of E.
Try to link executable against boost, too.
A shared library that itself includes statically linked libraries is not such a good idea, and I don't think that this scenario is well supported in the GNU toolchain.
I think that your particular problem arises from the option -static-libgcc, but I've been unable to compile it in my machine with your options. Not that linking statically-dinamically to libpthread.so sounds as such a good idea either... What will happen if the main executable wants to create its own threads? Will it be compiled with -pthread? If it is, then you will link twice the thread functions; if it isn't, it will have the functions but not the precompiler macros nor the thread-safe library functions.
My advice is simply not to compile your library statically, that's just not the Linux way.
Actually that should not be a real problem, even if you don't want to rely on the distribution version of boost: compile your program against the shared boost libraries and deploy all these files (libboost_thread.so.1.54.0, libboost_system.so.1.54.0 and libtestlib.so) to the same directory. Then run your program with LD_LIBRARY_PATH=<path-to-so-files>. Since the client is not intended to use boost directly, it doesn't need the boost headers, nor link them in the compiler command. You still have your black box, but now it is formed by 3 *so files, instead of just 1.
I recently started using CodeBlocks and began encountering odd runtime errors which I have traced back to printing strings using cout <<. For example, even the following..
#include <string>
#include <iostream>
int main()
{
std::string str;
str = "Hi!";
std::cout << str << std::endl;
return 0;
}
results in an error. It will compile fine (using Borland) but when I run it I get a pop up window saying 'test.exe has stopped working' and in the console I get the message:
Process returned -1073741819 (0xC0000005) execution time : 1.526 s
Press any key to continue.
It compiles and runs fine in MS Visual C++ and with G++ in Ubuntu.. any thoughts would be greatly appreciated!
Cheers,
Weatherwax
My one-off comment ended up helping solve the problem so here it is packaged up as an answer for future users:
This guy had a similar issue and it ended up being a linker issue which he
fixed. The fix is the last post in the thread, although reading the
whole thread could be useful for you.
Long Story short: Borland compiler is a bit dated and annoying to use. Ended up being a linker issue within borland. Better off using a different compiler like GCC/G++ or Visual Studio compiler.
This answer is here to elaborate on the root cause of the issue.
The reason for your crashing program is because the wrong runtime library is being linked. Specifically, your example is compiled as a single threaded object file(the default) but the linking step is using the multithreaded cw32mt.lib runtime -- the "mt" suffix at the end means multithreaded.
The solution is to make sure the runtime your program is compiled to use matches with the runtime you're linking against. A few ways to do this.
Important bcc32 compile switches:
-tW Windows GUI program. WinMain() is expected
-tWC Windows Console program. main() is expected. default.
-tWR Use dynamically linked runtime. Absence implies static runtime linkage.
-tWM Use multithreaded runtime. Absence implies single thread.
Compiling your example program as single threaded like this works:
bcc32 -oexample.obj -c example.cpp
ilink32 -ap example.obj c0x32, example.exe,, cw32.lib import32.lib,,
or you can compile it as multithreaded like this(note the -tWM switch matching up with cw32mt.lib):
bcc32 -tWM -oexample.obj -c example.cpp
ilink32 -ap example.obj c0x32, example.exe,, cw32mt.lib import32.lib,,
A third approach that is easier and less error prone is to not call the linker yourself. Instead, let the compiler drive the linker indirectly(similar to gcc):
bcc32 -tWM -oexample.obj -c example.cpp
bcc32 -tWM example.obj -eexample.exe
For your simple example, it can even be shortened to:
bcc32 -eexample.exe example.cpp
Lastly, you can pass the -tW switch multiple times. For example, this command compiles your example as a console program with multithread support and dynamic runtime linkage:
bcc32 -tWM -tWR -tWC -eexample.exe example.cpp
The produced example.exe executable is much smaller and its import table has an entry for CC3250MT.DLL confirming that the borland runtime is dynamically linked.
We should not assume that a non-functioning program is caused by nonconformity to the standard or a bug in the tool we're using without first investigating user error as a potential cause (even though in this case it's tempting to do so). In the OP's case, the code::block IDE didn't have the right commands setup for the toolchain being used.
Here is a simple MPI "Hello, World!" program.
#include <stdio.h>
#include <mpi.h>
int main(int argc, char **argv)
{
int size, rank;
MPI_Init(&argc, &argv);
MPI_Comm_size(MPI_COMM_WORLD, &size);
MPI_Comm_rank(MPI_COMM_WORLD, &rank);
printf("SIZE = %d RANK = %d\n",size,rank);
MPI_Finalize();
return(0);
}
However, it doesn't seem to compile:
Undefined first referenced
symbol in file
MPI::Datatype::Free() /var/tmp//ccE6aG2w.o
MPI::Win::Free() /var/tmp//ccE6aG2w.o
MPI::Comm::Comm() /var/tmp//ccE6aG2w.o
ld: fatal: symbol referencing errors. No output written to main
collect2: ld returned 1 exit status
I've googled a lot, viewed mailing lists, thousands of them. They say libmpi_cxx is not linking. But it's in the compiler flags.
Here is --showme data:
mpic++ --showme:compile
-I/usr/openmpi/ompi-1.5/include -I/usr/openmpi/ompi-1.5/include/openmpi
mpic++ --showme:link
-R/opt/mx/lib -R/usr/openmpi/ompi-1.5/lib -L/usr/openmpi/ompi-1.5/lib -lmpi -lopen-rte -lopen-pal -lnsl -lrt -lm -ldl -lsocket -lmpi_cxx
My compiler is g++.
Just place the mpi.h header file above all header files
sometimes that causes problem to compile
I am not sure how u execute your code.
Compiling
mpic++ your_code_file.c
Execution
mpirun -np <no. of Processors> ./a.out
A few notes:
Note that Open MPI 1.5 is ancient. Please upgrade to the latest version in the Open MPI 1.6.x series (which is currently 1.6.3, but note that the www.open-mpi.org web site is currently undergoing a planned year-end maintenance and won't be back up until later today, Thursday, December 28, 2012).
I'm curious: why are you compiling a C program with mpic++? You only need to use mpicc -- the C MPI wrapper compiler. That would definitely avoid your issue. However, if you are using this small C hello world program as a simple example and your actual target is to compile a C++ MPI program, then mpic++ is the correct wrapper to try (even with a simple C program). If that's the case, then you have some kind of incompatibility / misconfiguration between your C++ compiler and the C++ compiler that Open MPI was compiled/installed with.
Looking at your mpic++ --showme output, it looks like you have some kind of package distribution of Open MPI -- -R is not put in the flags by default, for example. Where did you get this Open MPI installation? It's quite possible that it is not (fully) compatible with your g++ installation (e.g., if it was compiled with a different version of g++).
That being said, your mpic++ --showme output is also weird in that it lists -lmpi_cxx at the end of the line. It should be to the left of -lmpi, not to the right of it. I'm not show how your installation got borked like that, but that is another possible cause.
So to sum up, my answer is:
Please try upgrading Open MPI and see if the problem goes away.
Double check that your installation of Open MPI is compatible with your system.
It is a also much easer and more flexible to compile openmpi and mpi programs in a "Eclipse for Parallel Application Developers" IDE.
http://www.eclipse.org/downloads/packages/eclipse-parallel-application-developers/junosr1
I am pretty new to Ubuntu, but I can't seem to get this to work. It works fine on my school computers and I don't know what I am not doing. I have checked usr/include and time.h is there just fine. Here is the code:
#include <iostream>
#include <time.h>
using namespace std;
int main()
{
timespec time1, time2;
int temp;
clock_gettime(CLOCK_PROCESS_CPUTIME_ID, &time1);
//do stuff here
clock_gettime(CLOCK_PROCESS_CPUTIME_ID, &time2);
return 0;
}
I am using CodeBlocks as my IDE to build and run as well. Any help would be great, thank you.
Add -lrt to the end of g++ command line. This links in the librt.so "Real Time" shared library.
example:
c++ -Wall filefork.cpp -lrt -O2
For gcc version 4.6.1, -lrt must be after filefork.cpp otherwise you get a link error.
Some older gcc version doesn't care about the position.
Since glibc version 2.17, the library linking -lrt is no longer required.
The clock_* are now part of the main C library. You can see the change history of glibc 2.17 where this change was done explains the reason for this change:
+* The `clock_*' suite of functions (declared in <time.h>) is now available
+ directly in the main C library. Previously it was necessary to link with
+ -lrt to use these functions. This change has the effect that a
+ single-threaded program that uses a function such as `clock_gettime' (and
+ is not linked with -lrt) will no longer implicitly load the pthreads
+ library at runtime and so will not suffer the overheads associated with
+ multi-thread support in other code such as the C++ runtime library.
If you decide to upgrade glibc, then you can check the compatibility tracker of glibc if you are concerned whether there would be any issues using the newer glibc.
To check the glibc version installed on the system, run the command:
ldd --version
(Of course, if you are using old glibc (<2.17) then you will still need -lrt.)
I encountered the same error. My linker command did have the rt library included -lrt which is correct and it was working for a while. After re-installing Kubuntu it stopped working.
A separate forum thread suggested the -lrt needed to come after the project object files.
Moving the -lrt to the end of the command fixed this problem for me although I don't know the details of why.