3

Why building static library (.a) doesn't give any error and works correctly:

$(LIBRARY): assertion.o
    $(AR) $(OUTPUT_STATIC_LIB_DIR)/$(LIBRARY) $(OUTPUT_DIR)/assertion.o

Simultaneously, when building shared library (.so) gives me such error: 

$(SHARED_LIBRARY): assertion.o
    $(CC) $(CFLAGS) -shared -o $(OUTPUT_LIB_DIR)/$(SHARED_LIBRARY) $(OUTPUT_DIR)/assertion.o

Error message:

Undefined symbols for architecture x86_64:
  "_float_cmp_func", referenced from:
Embedded C
  • 1,448
  • 3
  • 16
  • 29
Michał Ziobro
  • 10,759
  • 11
  • 88
  • 143

1 Answers1

0

The code of your library does refer to "_float_cmp_func", which needs to be found at run-time.

But static library is not expected to be a sufficient binary module, it is just collection of object code that is designed to be included into a later build/link steps (together with other object code and libraries).

In contrast, shared library is "ready-to-use" binary module, so its dependencies should be resolved at link stage. So in this case you should add into your link step some module(s) where "_float_cmp_func" is implemented

mvidelgauz
  • 2,176
  • 1
  • 16
  • 23
  • The error in question is an OSX thing - you can't create a dylib/so that has unbound references by default (you're allowed to do this in linux). – Anya Shenanigans Jun 06 '17 at 12:25
  • Thank you @Petesh for clarification :) – mvidelgauz Jun 06 '17 at 13:41
  • If I understand correctly It means that when I have several projects i.e. output libraries that depends on each other. Than when using static libraries I am archiving each project into .a file and then final project that uses this several libraries (ex. 10 libraries) must link to this (ex. 10 ) libraries. But when I am using .so files then final project may link to some 1 library that have dependecies to other libraries that have dependencies to other libraries, i.e with static libraries to compile each project I need to repeat linking with the same library and when using shared libraries not – Michał Ziobro Jun 06 '17 at 13:47
  • 1
    Yes, `.a` files just contain the code that applies to that library and cannot say that it depends on something else - e.g. code in another `.a`. When you build a `.so` you can link it to depend on another library, so the user would only need to link to the parent `.so` file, rather than all the other `.so` files as well. e.g. `gcc -shared -fPIC -o libb.so -L. -la` would make `libb.so` depend on `liba.so` at run-time as well. – Anya Shenanigans Jun 06 '17 at 13:53