How do you link correctly in C to stop symbols being stripped?

I'm having some trouble linking properly against libraries in C.

I'm sure this is one of those arcane C linking rules I don't fully understand, but I can't figure it out.

I have libn, which I compile into a static libary, libn.a

nm libn shows:

doug@ninja:~/projects/libnw/build$ nm ../../libn/build/libn.a |grep nIndex
00000034 T nIndex
00000000 D nIndex_
00000026 T nIndex_finalize
00000013 T nIndex_init
00000000 T nIndex_map

I also have libnw, which depends on libn. nm on libnw shows:

doug@ninja:~/projects/libnw/build$ nm libnw.a |grep Index
         U nIndex

However, when I compile a programming linking against libnw and libn I get:

doug@ninja:~/projects/libnw/build$ make
[ 70%] Built target nw
[ 80%] Built target test-template
Scanning dependencies of target test-Core
[ 85%] Building C object tests/nw/mvc/Core/CMakeFiles/test-Core.dir/Tests.c.o
[ 90%] Building C object tests/nw/mvc/Core/CMakeFiles/test-Core.dir/test.c.o
Linking C executable test-Core
../../../../libnw.a(Impl.c.o): In function `nwCore__Impl_init':
/home/doug/projects/libnw/src/nw/mvc/Core/Impl.c:76: undefined reference to `nIndex'
collect2: ld returned 1 exit status
make[2]: *** [tests/nw/mvc/Core/test-Core] Error 1
make[1]: *** [tests/nw/mvc/Core/CMakeFiles/test-Core.dir/all] Error 2
make: *** [all] Error 2

The reason, is quite clear. When Tests.c --> Tests.c.o, it's not picking nIndex up as a symbol it needs to keep:

doug@ninja:~/projects/libnw/build$ nm tests/nw/mvc/Core/CMakeFiles/test-Core.dir/Tests.c.o 
         U MyController
000005a4 T Tests
00000000 D Tests_
00000125 T Tests_can_attach_controller
00000080 T Tests_can_create_core
000003d3 T Tests_can_handle_native_event
000001c8 T Tests_can_set_controller
00000322 T Tests_can_update
00000000 t Tests_core_factory
0000056c T Tests_finalize
000005c0 T Tests_getType
0000048c T Tests_init
         U nFactory
         U nTest
         U nType_nalloc
         U nType_nfree
         U nwCore
         U nwDummyContext_getType
         U nwDumm开发者_运维问答yEvents_getType
         U nwDummyRender_getType
         U nwIContext_getType
         U nwIEvents_getType
         U nwIRender_getType

(Notice the total absence of U nIndex in the tests object file).

So, I can fix this easily by adding a call to nIndex() in my tests script, but that doesn't solve the basic problem:

Program depends on liba depends on libb, liba has missing symbols from libb it needs to resolve, but program has no references to those symbols, so they seem to be being stripped.

What am I doing wrong?

(Yes, I'm building using cmake and depending on the statically built versions of libn and libnw).

Edit:

Now with linker line:

/usr/bin/gcc  -std=c99 -g   CMakeFiles/test-Core.dir/Tests.c.o \
      CMakeFiles/test-Core.dir/test.c.o \
      CMakeFiles/test-Core.dir/helpers/MyController.c.o \
      CMakeFiles/test-Core.dir/helpers/MyModel.c.o \
      -o test-Core -rdynamic \
      /home/doug/projects/tapspin-android/source/deps/libn/build/libn.a \
      ../../../../libnw.a 

I don't see you link line so i's hard to tell for sure but this seems like it could be an ordering problem

If all of the symbols that are needed by libb are in liba, then you should list libb first, so that they are listed as symbols-to-be-resolved, and when libb is visited they will be resolved. This is not stripping per-se, it is just not including (i.e. it is omission not an active removal, am I splitting hairs? maybe)

Also, sometimes if there is a cyclical dependency (liba needs some symbols from libb and libb needs some symbols from liba) one has to list the libs multiple times (this is not a cmake answer as I do not use cmake, but have used linkers for many years, this where is a common error).

Note that unlike symbols from libraries, all symbols from object files are linked

Easiest fix to try first is just swap the order of the two libs

Since it is a problem of linking order, you can also solve it by using

--start-group

--end-group

GCC: what are the --start-group and --end-group command line options?

It works as long as we are speaking about static libraries/archive files.

To find the correct order of dependent libraries, the following *nix command pipeline can be used:

lorder libA.a libB.a ... | tsort

If one gets an error about a cyclical reference, then although the above GCC kludge using --start-group and --end-group will work, or simply listing the offending libraries a second time, one really ought to fix the libraries so they don't have cyclical dependencies.