0

Running into linker issues when using extern C functions in C++. Following other questions users have had answered I'm still coming up short. Example below...

---foo.h---

#ifdef __cplusplus
extern "C" {
#endif
extern int testFunc(int var);
#ifdef __cplusplus
}
#endif

---foo.c---

#include "foo.h"
int testFunc(int var)
{
  /* do stuff here... */ 
}

---bar.cpp---

#ifdef __cplusplus
extern "C" {
#endif
extern int testFunc(int var);
#ifdef __cplusplus
}
#endif

And when I call testFunc in my C++ file I get undefined reference to 'testFunc'. Not sure what I'm doing wrong, trying to base my solution off of previously answered questions but each example does something like this. How daft am I here?

Noble
  • 104
  • 10
  • There's nothing obviously wrong with the shown code, therefore the problem must be in the code that's not shown. The shown code does not meet stackoverflow.com's requirements for a [mre]. Please review those requirements, then [edit] your question. Until then, it is unlikely that anyone will be able to tell you anything else. – Sam Varshavchik Oct 21 '20 at 15:22
  • 2
    "but each example does something like this" and thats also what we can see. Can you provide more details so we can find what you are doing differently? Please try to provide a [mcve] – 463035818_is_not_an_ai Oct 21 '20 at 15:23
  • This could just be highlighting my ignorance, but the keyword `extern` is not in the C language, right? I'm surprised it compiles. – sweenish Oct 21 '20 at 15:29
  • Working within vxWorks. The 'testFunc' is located within my NIC driver layer (in C). The idea is to create a callback to use within my application layer (C++) to trigger a specific send mechanism. I have inline helper functions that are static within my foo.h file and I can use those and build just fine. I only run into issues when I try to declare in my .h and define in my .c. The specific NIC sending mechanism is a static function within the .c - which is the reason I need to define this callback 'testFunc' in my .c file. – Noble Oct 21 '20 at 15:30
  • 1
    Assuming your build script (or other means of controlling the build) compiles both foo.c and bar.cpp AND then includes the corresponding object files (e.g. foo.o and bar.o) in the link, there shouldn't be a problem. My guess is that you are forgetting to include foo.o in the link. – Peter Oct 21 '20 at 15:31
  • @Peter this sounds plausible. I could be incorrectly defining the linking. I have concatenating makefiles that rely on one another. – Noble Oct 21 '20 at 15:35
  • 1
    @sweenish: The keyword `extern` definitely is part of C. Using it to define language linkage ala `extern "C"` is not. – Ben Voigt Oct 21 '20 at 15:51
  • @SamVarshavchik: The only thing "obviously wrong" with the code in the question is that `bar.cpp` duplicates the prototype when it should merely `#include "foo.h"` – Ben Voigt Oct 21 '20 at 15:53
  • 1
    @Noble: [Run a tool such as `nm` or `objdump`](https://stackoverflow.com/q/392142/103167) on `foo.o` to make sure the function is exported with the expected name. It's possible you have accidentally marked it `static` (if so, it's probably indirectly done via a macro so you didn't immediately notice) and listing the export table of `foo.o` will tell you quickly. If you are compiling `foo.c` in C++ mode without knowing it, and thus exporting a mangled symbol, looking at the symbol table will tell you that too. – Ben Voigt Oct 21 '20 at 15:56

0 Answers0