![]() Rpath is defined in the dynamic section of an elf. Let's dump the content of the elf after compiling using cmake and check whether the rpath is set or not. target_link_libraries(Test $/Add/Build to the rpath. ![]() The dynamic loader uses the rpath to find the required needed library. Rpath is a run time search path hardcoded into an elf file. The answer is simply " rpath" What is rpath? So, Why with CMake the executable is running smoothly and does not while using makefile? Let's try compiling using makefileįrom the above snippet, it is obvious that the dynamic loader could not load libadd.so to resolve "add" symbol in run time. So, in run time when launching the executable, when it comes to execute the add function, the dynamic loader will load the shared object "libadd.so" into the executable memory space and resolve the "add" symbol.Īnd it works as expected. That's why in the CMakeLists.txt we tell the linker that you can resolve the undefined symbols by searching for these symbols in "libadd.so" and "add" in main.cpp is undefined symbol. To generate an executable we have to resolve all the undefined symbols. Main.cpp is utilizing "add" function, where the definition of the add function is in the shared object "libadd.so". Now I can reuse the add function from the shared object without implementing the function once again. Suppose you have a shared library libadd.so, it has a single function that adds two numbers.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |