0

I'm building a dynamic library c which is linked to a static library b.

The static library b is statically linked to the static library a.

The cmake for c, roughly looks like this (the cmakes for a and b are quite similar):

cmake_minimum_required(VERSION 2.6)
project(c)

include_directories(../b/src)
link_directories(../b/Debug)

add_library(c SHARED src/c.cpp)
target_link_libraries(c PRIVATE b)

The issue I'm facing is related to the fact that c can't see references to functions defined in a:

b.lib(b.obj) : error LNK2019: unresolved external symbol "int __cdecl a(void)" (?a@@YAHXZ) referenced in function "int __cdecl b(void)" (?b@@YAHXZ) [C:\Users\user\Workspace\garbage\c\c.vcxproj]
C:\Users\user\Workspace\garbage\c\Debug\c.dll : fatal error LNK1120: 1 unresolved externals [C:\Users\user\Workspace\garbage\c\c.vcxproj]

Is there any way for c to properly link?

Related questions:

Linking static libraries to other static libraries

pygabriel
  • 9,840
  • 4
  • 41
  • 54
  • 2
    static libraries are not linked ,they are merely a collection of object-files put together. Executables (exe's & dll's) are linked ,so to make an executable you need to supply all static libraries that are needed. – engf-010 Oct 23 '18 at 23:54
  • @engf-010 ??? [Static linking](https://en.wikipedia.org/wiki/Linker_(computing)#Static_linking) –  Oct 24 '18 at 00:00
  • @J. Doe: Yes ,that's exactly what I said in my comment. – engf-010 Oct 24 '18 at 00:03
  • @engf-010 Thats still called linking. –  Oct 24 '18 at 00:04
  • @J. Doe: Yes ,in the process of making an executable. That is either an exe or a dll. – engf-010 Oct 24 '18 at 00:06
  • 1
    @engf-010 so in this case the solution would be to provide both `a` and `b` when I want to produce a `c` executable? Reason being, statically linking `a` to `b` won't bundle the contents of `a` into `b`, it actually won't do anything at all – pygabriel Oct 24 '18 at 00:10
  • Precisely ,I couldn't have worded it better. – engf-010 Oct 24 '18 at 00:11
  • The process of making a library is often called archiving. Hence the .a extension of libraries on unix-like systems. – engf-010 Oct 24 '18 at 00:14

1 Answers1

-1

Something tells me that your linker output is not quite right. It looks like perhaps a and b are trying to be exported classes.

That aside, this line tells us that b cannot actually see some symbol (perhaps the class default constructor) for library (class) a:

b.lib(b.obj) : error LNK2019: unresolved external symbol "int __cdecl a(void)" (?a@@YAHXZ) referenced in function "int __cdecl b(void)" (?b@@YAHXZ)

In fact, your CMake example never links a to b and, your original questions says that b is linked into a. If you mean what you said in your question, you linker shows the logic error.

9301293
  • 514
  • 3
  • 16
  • The CMakes for `a` and `b` are not shown for brevity, as they are quite similar (`b` links `a` in an identical way, while `a` links nothing). In this case, `int a() {return 42;}` and `int b() {return a();}` and `int c(){return b()}` are all functions – pygabriel Oct 24 '18 at 16:21