On 6/15/07, Shriramana Sharma <samjnaa@xxxxxxxxx> wrote:
Glynn Clements wrote: > Libraries can have undefined references. Sometimes this is necessary, > e.g. if the library depends upon a function which is supposed to be > provided by the executable. To my mind, in the real world, if a library must access a function that the executable provides, it will only be through a function pointer -- the library may provide, for e.g. a binary search facility, and the program uses this to carry out a binary search on a function in its body.
Actually, that's what you do when you allow the function called by the library to have any name: you call it by a pointer. It is more flexible, but not necessarily the only way around.
What real world application would make a library A to call a function foo() when foo() is defined in the body of an executable X that itself depends on A? If foo() were in a dependency of A, say library B, then it can be understood, but to expect the function to come from X is, although *theoretically* possible, how practically necessary?
I suppose it is just because it is more simple and flexible to implement it this way. Because for library A (and for the compiler and linker) it doesn't matter if foo() comes from executable X or library B. At compile time, those symbols are simply inserted in the table of defined symbols, so it doesn't matter where they come from (and C doesn't even have namespaces or something like that anyway; symbols are just global or local).
>> This seems highly counter-intuitive. Why would the linker require *only* >> at *executable* build-time the libraries, > > Why would the linker require all external symbols to be resolved at > the time the library is built? If you prove that there is a valid real-life situation where the library needs a symbol from an application, then the linker would not require all external symbols to be resolved.
Here is an example of library using a symbol from the application: the external environ variable referenced in unistd.h is defined by the application. The exec* family of functions (excluding execle() I guess) use it internally only. Cheers, Pedro. -- Pedro de Medeiros - Ciência da Computação - Universidade de Brasília Home Page: http://www.nonseq.net - Linux User No.: 234250 - To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html