On Thu, Jan 13, 2005 at 04:11:22PM +0100, M?ns Rullg?rd wrote: > Brian Thomas Sniffen <bts@alum.mit.edu> writes: > > > Combining X+Y in the way that you have described is anything but > > mechanical: it is a task which typically takes a skilled programmer a > > great amount of time and thought. Different programmers might do it > > in different ways. I'm not referring here to the work done by ld, but > > to the process of building a new program which has libfoo as a > > component. > > > > Additionally, the program ultimately delivered to the user isn't X > > with some minor bits of Y. It contains big chunks of Y -- one per > > function used, at least -- directly copied. Just being in a different > > memory space isn't enough to change the relationship between the > > creative parts of the works. The program vim encompasses a copy of > > libc. > > Wrong. A dynamically linked program in ELF format (the most common on > Linux systems) contains a list of undefined symbols, and a list of > sonames to search for those symbols. I have a hard time seeing how > this would make a program derived from the library. If multiple > independent implementations of the library exist, which would the > program be derived from? You've got the causality backwards here. The program is linked to the libraries because it is a derivative of the libraries. Not the other way around. Derivation is something that happens when you *write* the program. Not when you build it. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- |
Attachment:
signature.asc
Description: Digital signature