2

I apologize ahead of time if my terminology is incorrect.

Let's say I have a shared library called libVectorMath.so. In it are two interesting functions, addVector() and subtractVector(). The two functions are prototyped in vectorMath.h. I also have an executable called testVectorMath, which uses those two functions, and is dynamically linked to libVectorMath.so.

Generally speaking, to build testVectorMath, I need to build libVectorMath.so as well. Why is this? Is the header file vectorMath.h not sufficient to tell testVectorMath what symbols it should expect to find in libVectorMath.so?

In other words, can't testVectorMath have some instructions in it to say "look for a library called libVectorMath.so and then look for symbols named addVector() and subtractVector() within it"?

Adam S
  • 8,945
  • 17
  • 67
  • 103

1 Answers1

1

Read this link. Its tells about the same in a very good way!

An Excerpt from above is as follows: All shared library schemes work essentially the same way. At link time, the linker searches through libraries as usual to find modules that resolve otherwise undefined external symbols. But rather than copying the contents of the module into the output file, the linker makes a note of what library the module came from, and puts a list of the libraries in the executable. When the program is loaded, startup code finds those libraries and maps them into the program's address space before the program starts, Figure 1. Standard operating system file mapping semantics automatically share pages that are mapped read-only or copy-on-write. The startup code that does the mapping may be in the operating system, the executable, in a special dynamic linker mapped into the process' address space, or some combination of the three.

MAG
  • 2,841
  • 6
  • 27
  • 47