I'm using GPU Ocelot in order to build CUDA programs since I don't have access to an NVIDIA GPU. I'm compiling the sample code using nvcc and linking using g++. I'm doing this since I need to link a C++ program against a static library built using nvcc.
Here are the commands I'm using:
$ nvcc -c cudaMemCheck.cu
$ g++ -o cudaMemCheck cudaMemCheck.o -locelot
This results in the following error:
cudaMemCheck.o: In function `main':
tmpxft_00006ca0_00000000-1_cudaMemCheck.cudafe1.cpp:(.text+0x2e): undefined reference to `cudaMemGetInfo'
collect2: ld returned 1 exit status
I have the following code in cudaMemCheck.cu:
#include <stdlib.h>
#include <stdio.h>
int main(int argc, char **argv)
{
size_t free, total;
cudaMemGetInfo(&free, &total);
fprintf(stdout, "free = %zu | total = %zu\n", free, total);
return 0;
}
Oddly enough, this method of compiling and linking seems to work if I link with nvcc. The program I'm linking the CUDA library against is an MPI program that uses the mpic++ wrapper for compilation, so I'm not sure I can use nvcc for linking.
Also I want to note that using g++ to link source files that use other functions in the CUDA Runtime (e.g. cudaMalloc) seems to work just fine.
Any help would be greatly appreciated.
As you can see for yourself here, the Ocelot developers never added cudaMemGetInfo to their runtime implementation. cudaMemGetInfo was a relatively new addition to the runtime API (appeared in CUDA 4 IIRC), and Ocelot was most actively developed against CUDA 2 and CUDA 3.
You only two choices are to not use it, or add your own implementation (it could be an empty stub if you like) and link that.
Related
This question already has answers here:
How to change entry point of C program with gcc?
(4 answers)
Closed 5 years ago.
I am trying to compile a function (not called main) that can be integrated in another code or directly executed (after linking).
I try it one my mac, and work well.
I finally test it on Linux (CentOS and ubuntu). However, the task looks harder as expected on Linux.
The source code is the following one (just to explain the problem)
test.cpp:
#include <cstdio>
#ifdef __cplusplus
extern "C" {
#endif
int test(int argc, char const *argv[]);
#ifdef __cplusplus
}
#endif
int test(int argc, char const *argv[]) {
fprintf(stderr, "%s\n", "test");
return 0;
}
Compilation line on MacOS
g++ -c test.cpp -o test.o && g++ test.o -o test -e _test
and on Linux
g++ -c test.cpp -o test.o && g++ test.o -o test -e test
I try on my MacOS with clang, g++ and Intel compiler, all 3 works fine.
And I try with g++ and the Intel compiler on Linux, always, the same error.
usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
collect2: error: ld returned 1 exit status
Any advice, explanation or solution, on what I am doing wrong or missing would be very helpful.
Thanks
Edit:
Currently, I have a "define" to create a main, but if we have lots of function we are obligated to do two compilations each time (one for the function version and one for the execution) and make finally the code heavier.
Like discussed in this topic is there a GCC compiler/linker option to change the name of main?
To don't do a XY I inherited from a bunch of small programs that I want to put to gather, that it is easier to use (for remote execution ...). However, each one need to be able to be executed independently if needed, for debugging,... I hesitate, between using "execv" and just convert each main as a function. I probably take the bad chose.
Edit:
The final goal is to be able to have independent programs. But that we can call from an external software too.
Solution:
The solution looks to be, to a call to the main through a dlopen
You cannot do that (and even if it appears to work on MacOSX it is implementation specific and undefined behavior).
Linux crt0 is doing more complex stuff that what you think.
The C standard (e.g. n1570 for C11) requires a main function for hosted implementations (ยง5.1.2.2.1) :
The function called at program startup is named main. The implementation declares no prototype for this function.
And the C++ standard also requires a main and strongly requires some processing (e.g. construction of static data) to be done before main is running and after it has returned (and various crt0 tricks are implementing that feature on Linux).
If you want to understand gory details (and they are not easy!), study the ABI and the (free software) source code of the implementation of the crt0.
I am trying to compile a function (not called main) that can be integrated in another code
BTW, to use dynamically some code (e.g. plug-ins) from another program, consider using the dynamic linker. I recommend using the POSIX compliant dlopen(3) with dlsym(3) on position-independent code shared libraries. It works on most Unix flavors (including MacOSX & Linux & Solaris & AIX). For C++ code beware of name mangling so read at least the C++ dlopen mini howto.
Read also the Program Library HowTo.
Problems with libraries, they cannot be executed, no ?
I don't understand what that means. You certainly can load a plugin then run code inside it from the main program dlopen-ing it.
(and on Linux, some libraries like libc.so are even specially built to also work as an executable; I don't recommend this practice for your own code)
You might take several days to read Drepper's How To Write Shared Libraries (but it is advanced stuff).
If you want to add some code at runtime, read also this answer and that one.
The final goal is to be able to have independent program. But that we can call from an external software too
You can't do that (and it would make no sense). However, you could have conventions for communicating with other running programs (i.e. processes), using inter-process communication such as pipe(7)-s and many others. Read Advanced Linux Programming first and before coding. Read also Operating Systems : Three Easy Pieces
The solution looks to be, to a call to the main through a dlopen
Calling the main function via dlopen & dlsym is forbidden by the C++ standard (which disallows using a pointer to main). The main function has a very specific status and role (and is compiled specially; the compiler knows about main).
(perhaps calling main obtained by dlsym would appear to work on some Linux systems, but it certainly is undefined behavior so you should not do that)
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
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 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.
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.