How do you reference C correctly to stop character selection?

Question

I am having trouble correctly linking library links in C.

I am sure this is one of those secret C communication rules that I don’t quite understand, but I can’t understand.

I have libn, which I compile to 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 is dependent on libn. nm on libnw shows:

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

However, when I compile the link to connect to 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.co [ 90%] Building C object tests/nw/mvc/Core/CMakeFiles/test-Core.dir/test.co Linking C executable test-Core ../../../../libnw.a(Impl.co): 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 perfectly clear. When Tests.c → Tests.co, it does not select nIndex as the character to be saved:

 doug@ninja :~/projects/libnw/build$ nm tests/nw/mvc/Core/CMakeFiles/test-Core.dir/Tests.co 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 nwDummyEvents_getType U nwDummyRender_getType U nwIContext_getType U nwIEvents_getType U nwIRender_getType 

(Note the complete absence of U nIndex in the test object).

So, I can easily fix this by adding a call to nIndex () in my script tests, but this does not solve the main problem:

The program depends on liba, depends on libb, liba does not have any libb characters that must be resolved, but the program does not have references to these characters, so they seem to be lost.

What am I doing wrong?

(Yes, I use cmake and depending on statically built versions of libn and libnw).

Edit:

Now with the linker:

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

Answer 1

I don’t see you referring to the string, so it’s hard for me to say for sure, but it looks like it might be a problem with ordering.

If all the symbols that libb needs are in liba , then you must first list libb so that they are listed as symbols for resolution, and when libb they are resolved. This is not a cleaning per se, it just does not include (that is, this omission is not an active removal, am I splitting my hair? Maybe)

In addition, sometimes, if there is a circular dependency ( liba needs some symbols from libb , and libb needs some symbols from liba ), you need to list the libraries several times (this is not a cmake answer, since I have not used cmake , but have used links for many years , this is where the common mistake is).

Please note that unlike symbols from libraries, all symbols from object files are linked

The easiest fix for the first attempt is to simply reorder the two libraries

Answer 2

Since this is an order binding problem, you can also solve it using

- start group

- end of group

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

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

Answer 3

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

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

If an error occurs regarding a circular reference, then despite the fact that the aforementioned GCC clown using --start-group and -end-group will work or just list malicious libraries a second time, the libraries really need to be fixed, so they don’t have cyclic dependencies.