I want to compile mpi with my own libraries. And I'm not sure if the options that work on gcc such as -I/ -L/ are available for mpicc.
I'm trying to compile with the following options but I get the following error.
mpicc -I$(CURRENT_DIR)/util -I$(CURRENT_DIR) -L$(CURRENT_DIR)/util -o server server.c
mpicc -I./util -I. -L./util -o server server.c
/tmp/ccA5be6Z.o: En la función `main':
server.c:(.text+0x195): undefined reference to `list_create'
server.c:(.text+0x219): undefined reference to `list_add'
server.c:(.text+0x228): undefined reference to `list_count'
collect2: error: ld returned 1 exit status
Those are my server.c includes
#include <mpi.h>
#include <list.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <pthread.h>
And this is my pwd/util folder
$ ls
list.c list.h list.o
...
mpicc (and the other MPI build commands) are only wrappers on top of your compilers. So if you are using gcc, all the gcc options and directives are available.
Concerning OpenMPI, you can exhibit the compiler and the options used by using the --showme option. You can see the details in the OpenMPI FAQ (https://www.open-mpi.org/faq/?category=mpi-apps#wrapper-showme-with-no-file). Similar options are available in MPICH (https://www.mpich.org/static/docs/v3.2.x/www1/mpicc.html)
Your issue here is not related to MPI. You are just missing adding some objects (probably list.o) in the linking step. You should consider creating a Makefile to ease the build process.
Related
I'm working on a project (hangman.c) and I want to include a module I wrote from another directory (quicksort.h). Here is the top of my hangman.c file:
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <ctype.h>
#include "../quicksort/quicksort.h"
I've been running this command:
clang -o hangman hangman.c
And i get this error message:
/usr/bin/ld: /tmp/hangman-3292ab.o: in function `append_and_order':
hangman.c:(.text+0x26c): undefined reference to `quicksort'
clang: error: linker command failed with exit code 1 (use -v to see invocation)
I compile them separately and link them together manually with
gcc -c hangman.c
gcc -c ../quicksort/quicksort.c
gcc -o hangman hangman.o quicksort.o
(As corrected). And that works, but isn't the point of #include to do this automatically at the preprocessing stage?
I am trying to use portaudio in one of my projects. Unfortunately, I cannot compile my main.c file.
Error: "undefined reference to 'Pa_Initialize'" (Pa_Initialize is a function from the portaudio library)
My working directory includes the .a file from portaudio as well as the portaudio.h.
My current gcc command: gcc main.c libportaudio.a -lm -o main
Update: these are the includes in my main.c
#include <stdio.h>
#include <math.h>
#include "portaudio.h"
If you get an undefined reference error, you have probably already integrated the header file portaudio.h.
As Kurt E. Clothier already mentioned, you must also mention the libraries inside your gcc command. According to the portaudio website, the gcc command is
gcc main.c libportaudio.a -lrt -lm -lasound -ljack -pthread -o main
I was able to fix the issue by rebuilding the portaudio library.
I just have a system crash and reinstall Ubuntu 11.10, and my code produces this strange error.
I wrote a simple code sample to test where the problem is:
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <fcntl.h>
#include <sys/mman.h>
#include <sys/stat.h>
int main (void) {
int i;
i = shm_open ("/tmp/shared", O_CREAT | O_EXCL, S_IRUSR | S_IWUSR); printf ("shm_open rc = %d\n", i);
shm_unlink ("/tmp/shared");
return (0);
}
and the compile command is
gcc -lrt test.c -o test
The error is:
/tmp/ccxVIUiP.o: In function `main':
test.c:(.text+0x21): undefined reference to `shm_open'
test.c:(.text+0x46): undefined reference to `shm_unlink'
collect2: ld returned 1 exit status
I have already added -lrt lib, why does it still not compile?
Libraries at the end:
gcc test.c -o test -lrt
From GCC Link Options:
-llibrary
-l library
Search the library named library when linking.
(The second alternative with the library as a separate argument
is only for POSIX compliance and is not recommended.)
It makes a difference where in the command you write this option;
the linker searches and processes libraries and object files in the
order they are specified.
Thus, `foo.o -lz bar.o' searches library `z' after file foo.o but
before bar.o. If bar.o refers to functions in `z', those functions
may not be loaded.
Change the compile line from
gcc -lrt test.c -o test
to
gcc test.c -o test -lrt
In Expert C programming Page 108:
<Handy Heuristic>
Where to Put Library Options:Always put the -l library options at the rightmost end of your compilation command line.
But it doesn't tell why, so i guess this is somewhat a rule?:)
For those of you using super-auto-magical CMAKE like me, try to add:
target_link_libraries(your_binary_name PRIVATE librt.so)
to your CMakeLists.txt
Alternatively, replace PRIVATE for PUBLIC as needed..
If you have well established paths to libraries (e.g. all needed libs in /usr/lib), you may be fine with just stating in CMakeLists.txt:
set(CMAKE_CXX_FLAGS "-lrt")
I'm trying to compile mphidflash on Debian (Jessie) after re-writing the low-level USB interface to talk to libhidapi-libusb instead of libhid (which is no longer supported on Debian) but I'm getting some compiler errors that I'm not sure what do to with.
These are my includes in usb-linux.c:
#include <stdio.h>
#include <usb.h>
#include <hidapi/hidapi.h>
#include "mphidflash.h"
#include <errno.h>
and here are the commands I've tried which error:
$ gcc main.o hex.o usb-linux.o -lusb -lhidapi-libusb -o mphidflash
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libhidapi-libusb.so: undefined reference to `libusb_handle_events_completed'
collect2: error: ld returned 1 exit status
$ gcc main.o hex.o usb-linux.o /usr/lib/x86_64-linux-gnu/libhidapi-libusb.a -lusb -lhidapi-libusb -o mphidflash
/usr/bin/ld: /usr/lib/x86_64-linux-gnu/libhidapi-libusb.a(hid.o): undefined reference to symbol 'libusb_detach_kernel_driver'
//usr/local/lib/libusb-1.0.so.0: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
Basically, I'm getting an undefined reference to symbol 'libusb_detach_kernel_driver' which suggests that I'm including the libusb library incorrectly but I've no idea what else to try.
Turns out hidapi-libusb uses libusb-1.0 and not libusb-0.1 (both of which can be installed on Debian).
I changed the includes to be:
#include <stdio.h>
#include <libusb-1.0/libusb.h>
#include <hidapi/hidapi.h>
#include "mphidflash.h"
#include <errno.h>
And compiled with:
$ gcc main.o hex.o usb-linux.o -lusb-1.0 -lhidapi-libusb -o mphidflash
I'll be putting my changes into a git repo and I'll post the link when I'm finished.
I just have a system crash and reinstall Ubuntu 11.10, and my code produces this strange error.
I wrote a simple code sample to test where the problem is:
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <fcntl.h>
#include <sys/mman.h>
#include <sys/stat.h>
int main (void) {
int i;
i = shm_open ("/tmp/shared", O_CREAT | O_EXCL, S_IRUSR | S_IWUSR); printf ("shm_open rc = %d\n", i);
shm_unlink ("/tmp/shared");
return (0);
}
and the compile command is
gcc -lrt test.c -o test
The error is:
/tmp/ccxVIUiP.o: In function `main':
test.c:(.text+0x21): undefined reference to `shm_open'
test.c:(.text+0x46): undefined reference to `shm_unlink'
collect2: ld returned 1 exit status
I have already added -lrt lib, why does it still not compile?
Libraries at the end:
gcc test.c -o test -lrt
From GCC Link Options:
-llibrary
-l library
Search the library named library when linking.
(The second alternative with the library as a separate argument
is only for POSIX compliance and is not recommended.)
It makes a difference where in the command you write this option;
the linker searches and processes libraries and object files in the
order they are specified.
Thus, `foo.o -lz bar.o' searches library `z' after file foo.o but
before bar.o. If bar.o refers to functions in `z', those functions
may not be loaded.
Change the compile line from
gcc -lrt test.c -o test
to
gcc test.c -o test -lrt
In Expert C programming Page 108:
<Handy Heuristic>
Where to Put Library Options:Always put the -l library options at the rightmost end of your compilation command line.
But it doesn't tell why, so i guess this is somewhat a rule?:)
For those of you using super-auto-magical CMAKE like me, try to add:
target_link_libraries(your_binary_name PRIVATE librt.so)
to your CMakeLists.txt
Alternatively, replace PRIVATE for PUBLIC as needed..
If you have well established paths to libraries (e.g. all needed libs in /usr/lib), you may be fine with just stating in CMakeLists.txt:
set(CMAKE_CXX_FLAGS "-lrt")