从 (C) header 文件调用 C++ function 给出 Z3175B426046787EECE737B7378 错误

Question

I am integrating a library (lwip) and I want to reroute the logging mechanism from printf to something I wrote myself (which logs directly to my uart).

In some header file the following code exists

/** Platform specific diagnostic output.\n
 * Note the default implementation pulls in printf, which may
 * in turn pull in a lot of standard libary code. In resource-constrained 
 * systems, this should be defined to something less resource-consuming.
 */
#ifndef LWIP_PLATFORM_DIAG
#define LWIP_PLATFORM_DIAG(x) do {printf x;} while(0)
#include <stdio.h>
#include <stdlib.h>
#endif

I replaced this line

#define LWIP_PLATFORM_DIAG(x) do {printf x;} while(0)

with

#define LWIP_PLATFORM_DIAG(x) do {logLineToUart x;} while(0)

I am using the same signature for my function as the printf signature:

void logLineToUart(const char * log, ...);

And I placed that function in my own header lwiplogging.h , which I include in the header which defines LWIP_PLATFORM_DIAG

And, I implement the function in a C++ file:

void logLineToUart(const char * log, ...)
{
    uart3.Write(log);
    uart3.Write("\r\n");
}

NOTE: uart3 is an object of my Uart class. Hence it's C++ code. I suspect this is the problem, but I can't figure out how to correct my error. Adding extern "C" to the function doesn't seem to solve it either.

The linker error I get:

Linking .pio\build\nucleo_f446ze\firmware.elf
.pio/build/nucleo_f446ze/lib997/lwip/api/api_lib.o: In function `netconn_send':
api_lib.c:(.text.netconn_send+0x26): undefined reference to `logLineToUart'
.pio/build/nucleo_f446ze/lib997/lwip/api/sockets.o: In function `tryget_socket_unconn_nouse':
sockets.c:(.text.tryget_socket_unconn_nouse+0xa): undefined reference to `logLineToUart'
.pio/build/nucleo_f446ze/lib997/lwip/api/sockets.o: In function `get_socket':
sockets.c:(.text.get_socket+0x14): undefined reference to `logLineToUart'
.pio/build/nucleo_f446ze/lib997/lwip/api/sockets.o: In function `lwip_connect':
sockets.c:(.text.lwip_connect+0x22): undefined reference to `logLineToUart'
sockets.c:(.text.lwip_connect+0x38): undefined reference to `logLineToUart'
.pio/build/nucleo_f446ze/lib997/lwip/api/sockets.o:sockets.c:(.text.lwip_connect+0x7e): more undefined references to `logLineToUart' follow
collect2.exe: error: ld returned 1 exit status
*** [.pio\build\nucleo_f446ze\firmware.elf] Error 1

What am I doing wrong?

UPDATE

The error I get when I declare the function as extern "C"

UPDATE 2:

This does compile:

#ifdef __cplusplus
extern "C" {
void logLineToUart(const char * log, ...);

#endif

void logLineToUart(const char * log, ...);

#ifdef __cplusplus
}
#endif

Answer 1

extern "C" void logLineToUart(const char * log, ...);

You need to tell it to make the name C-linker compatible the first time it is seen.

update

The extern "C" is only when compiling as C++. It is not legal syntax in C. You can use extern by itself (it is implied if you leave it off).

Editorial

That's not very friendly... C++ accommodates sharing header files with C by accepting syntax that would not apply to C++, just to make it easy to use the same header file contents. In particular, using (void) for empty parameter lists (which is "an abomination") and allowing a comma in variadic function parameter lists ( (int x...) is how C++ originally defined it; when the same feature got incorporated into ANSI C they used (int x, ...) with a superfluous comma that is not needed by the grammar.) C++ compilers accept both of these to make it easier to consume C headers...

But, you have to add extern "C" around everything. This introduces conditional compilation anyway, even though C++ accepts the C syntax. Note that for a single declaration, extern int foo (int); the extern is allowed and implied if you leave it out. If the C compiler allowed the linkage specification even though only "C" is available, it would make life easier. Note that in most cases, the C and C++ implementation are the same compiler suite, and often one language supports some features of the other as extensions. It would be cool if gcc etc. supported extern "C++" in C mode, since that code base certainly does know how the name encodes the parameters.