undefined reference to a function c [duplicate] - c++

Question

This question already has answers here:
What is an undefined reference/unresolved external symbol error and how do I fix it?
(39 answers)
Closed 8 years ago.
This question maybe have been asked before. I could not find it to the best of my searches.
I'm trying to link libpfm4.5.0 in my code. The header file that I'm using is the following: perf_util.h
Here is the link to download libpfm4.5.0.
Does it matter where exactly I include the header file?
Here is a snippet of my code:
#include "matrix.h"
#include "perf_util.h"
int read_counts(int pid, int app_num){
int ret, i, num_fds = 0, grp, group_fd;
int ready[2], go[2];
char buf;
int nevents;
nevents = TOTAL_NUM_EVENTS;
go[0]=go[1] = -1;
for (grp = 0; grp < nevents; grp++) {
int ret;
ret = perf_setup_list_events(perf_events.pmc[grp], &fds_pid[app_num], &num_fds);
if (ret || !nevents)
exit(1);
}
}
the header file perf_util.h does contain perf_setup_list_events function but during compilation
matrix.o: In function `read_counts(int, int)':
matrix.c:(.text+0xf20): undefined reference to `perf_setup_list_events(char const*, perf_event_desc_t**, int*)'
collect2: error: ld returned 1 exit status
This is the error I get. What could be the possible places I would have done the error? Any help would be appreciated.
This is how I compile.
g++ -I. -I/libpfm-4.5.0/perf_examples/../include -DCONFIG_PFMLIB_DEBUG -DCONFIG_PFMLIB_OS_LINUX -I. -D_GNU_SOURCE -pthread -w -c matrix.c
g++ -I. -I/libpfm-4.5.0/perf_examples/../include -DCONFIG_PFMLIB_DEBUG -DCONFIG_PFMLIB_OS_LINUX -I. -D_GNU_SOURCE -pthread -w -o matrix matrix.o perf_util.o /libpfm-4.5.0/perf_examples/../lib/libpfm.a
Note: libpfm compiles using cc and I use g++. Could that be the problem? if yes, how should I solve it?
Here is how I compile it now:
cc -std=c99 -I. -I/libpfm-4.5.0/perf_examples/../include -DCONFIG_PFMLIB_DEBUG -DCONFIG_PFMLIB_OS_LINUX -I. -D_GNU_SOURCE -pthread -w -c matrix.c
cc -std=c99 -I. -I/libpfm-4.5.0/perf_examples/../include -DCONFIG_PFMLIB_DEBUG -DCONFIG_PFMLIB_OS_LINUX -I. -D_GNU_SOURCE -pthread -w -o matrix matrix.o perf_util.o libpfm-4.5.0/perf_examples/../lib/libpfm.a
error: expected ‘:’, ‘,’, ‘;’, ‘}’ or ‘__attribute__’ before ‘=’ token
const char * pmc[TOTAL_NUM_EVENTS] = {"blah", "blahbar"}
I've a const char * array and this is the error I get.

Answer 1

OK, so, contrary to what I thought at first, your program is a C++ program. We know this is the case because the C++ compiler accepts it and the C compiler doesn't. (You still haven't given enough information for me to understand why the C compiler doesn't like it, but I suspect it's something uninteresting like defining a file-scope variable that can't be fully initialized at compile time. If you meant this to be a C program you should ask a new question about that. Anyway.)
The library you are using is C, not C++, and its header files are not set up to be used from C++ programs. I deduced that this was the problem from the error message:
undefined reference to `perf_setup_list_events(char const*, perf_event_desc_t**, int*)'
See how that error message gives a full prototype for the function perf_setup_list_events? That's because C++ has function overloading and C doesn't -- so, in C++, every function is given a "mangled name" which encodes its prototype. If you do nm matrix.o | grep perf_setup_list_events you will discover this mangled name: it's probably something like _Z22perf_setup_list_eventsPKcPP17perf_event_desc_tPi. The linker is helpfully decoding that again to a prototype.
So, the fact that the linker error has a full prototype, all by itself, tells me that the undefined reference is from code compiled as C++. Now, I have never heard of libpfm4.5.0 before, but I do know that you would have gotten a different error message if your library didn't actually define that function -- something like
error: ‘perf_setup_list_events’ was not declared in this scope
So I guessed that the library is written in C, not C++, and that its header files are not written to handle being used from C++ programs. This is a defect in the library, but one that can be worked around by writing
extern "C" {
#include "perf_util.h"
}
instead of just the bare #include. The extern "C" { ... } construct tells a C++ compiler to not apply name mangling to whatever is declared within. Thus, your program, when compiled that way, looks for a symbol named perf_setup_list_events instead of _Z22perf_setup_list_eventsPKcPP17perf_event_desc_tPi and it links successfully.