"Undefined Reference To" Errors When Linking Static C Library With C++ Code

c++ undefined references with static library

This is probably a link order problem. When the GNU linker sees a library, it discards all symbols that it doesn't need. In this case, your library appears before your .cpp file, so the library is being discarded before the .cpp file is compiled. Do this:

g++ -o main.exe main.cpp -L. -lmylib

or

g++ -o main.exe main.cpp myClass.lib

The Microsoft linker doesn't consider the ordering of the libraries on the command line.

Linking C++ to static library; undefined reference errors

The library libEAPI.a contains object files compiled in C, not C++.
The symbols therefore have not been name-mangled and cannot serve to
resolve the name-mangled function references generated by your C++
code.

Run:

nm libEAPI.a | grep EApiFanDisable

and you will see no change.

Run:

nm main.o | grep EApiFanDisable

and you will see the mangled symbol, which is neither EApiFanDisable nor EApiFanDisable()
but something more like _Z14EApiFanDisablev, that the linker is actually trying
to resolve.

To avoid these linkage errors you must inform your C++ compiler, when it
compiles the header file(s) of libEAPI, that the declarations therein have
external C linkage, so it will emit unmangled references to the symbols declared: like so:

main.cpp

...
extern "C" {
#include "EAPI.h"   // or whatever
}

...

BTW, this commandline:

g++  -o secoTest -lpthread  main.o  libEAPI.a

will fail to link libpthread on a Debian-based distro (Ubuntu et al)
more recent than Debian 6, as all libraries must be linked in dependency order since then:

g++  -o secoTest main.o  libEAPI.a -lpthread

Even better, do not use the non-portable -lpthread and pass the portable
option -pthread for both compilation and linkage. It means: Do whatever
is right to compile/link with Posix Threads support

Undefined reference when linking with static library, but successful link when compiling with src

I haven't seen all your code, but the problem is most likely caused by how static linking works (http://eli.thegreenplace.net/2013/07/09/library-order-in-static-linking/).

Try changing the order of the libraries, and specifically, try changing this:

$(MODULE_EXE): $(OBJS)
  $(CC) $(LIB_DIRS) $(LIBS) $(LINKER_OPTS) -o $@ $^ 

into this:

$(MODULE_EXE): $(OBJS)
  $(CC) $(LIB_DIRS) $(LINKER_OPTS) -o $@ $^ $(LIBS)

undefined reference to errors when linking static C library with C++ code

But everything works well with other C programs linking this library.

Did you notice that C and C++ compilation create different symbol names on object file level? It's called 'name mangling'.

The (C++) linker would show undefined references as demangled symbols in the error message, which might confuse you. If you inspect your test.o file with nm -u you'll see that the referenced symbol names don't match with those provided in your library.

If you want to use functions linked in as externals that were compiled using the plain C compiler, you'll need their function declarations enclosed in an extern "C" {} block which suppresses C++ name mangling for everything declared or defined inside, e.g.:

extern "C" 
{
    #include <dual/xalloc.h>
    #include <dual/xmalloc.h>
}

Even better, you might wrap your function declarations in your header files like this:

#if defined (__cplusplus)
extern "C" {
#endif

/*
 * Put plain C function declarations here ...
 */ 

#if defined (__cplusplus)
}
#endif

CMake doesn't link C and C++ static libraries (undefined reference to function)

The problem here is, that the linker relies on the order of the libraries. With

target_link_libraries(prog funcc_lib funccpp_lib)

It first links funcc_lib and then funccpp_lib. But it never gets back to funcc_lib. Since funccpp_lib depends on funcc_lib, you have to change the order of the libraries:

target_link_libraries(prog funccpp_lib funcc_lib)

For additional information, see this discussion.

Undefined reference while linking static C library

The problem is the linker (gcc), like most linkers, processes the parameters from left to right. so the link sees the libraries, but there is no unresolved references to be handled, so nothing happens.

The fix is to place the libraries last on the line rather than just after the CFLAGS.

Undefined reference in static library to global symbol included in an earlier included static library?

Libraries have to at the end of the command line. ld is searching only one time for the symbols in the library.

LDFLAGS=-L/home/john/deps/install/opt/riscv/lib/gcc/riscv64-unknown-elf/8.1.0 -L/home/john/musl-1.1.23/install/lib -lcrt1 -lgcc -lc 

--library=archive
Add archive file archive to the list of files to link. This option may be used any number of times. ld will search its path-list for
occurrences of libarchive.a for every archive specified. On systems
which support shared libraries, ld may also search for libraries with
extensions other than .a. Specifically, on ELF and SunOS systems, ld
will search a directory for a library with an extension of .so before
searching for one with an extension of .a. By convention, a .so
extension indicates a shared library. The linker will search an
archive only once, at the location where it is specified on the
command line. If the archive defines a symbol which was undefined in
some object which appeared before the archive on the command line, the
linker will include the appropriate file(s) from the archive. However,
an undefined symbol in an object appearing later on the command line
will not cause the linker to search the archive again. See the -(
option for a way to force the linker to search archives multiple
times. You may list the same archive multiple times on the command
line. This type of archive searching is standard for Unix linkers.
However, if you are using ld on AIX, note that it is different from
the behaviour of the AIX linker.

Error while linking static library to test script

After reading this SO question, I realized that I had missed an overridden virtual member.

---

Related Topics