Måns Rullgård <[EMAIL PROTECTED]> writes: > Brian Thomas Sniffen <[EMAIL PROTECTED]> 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?
ELF format has nothing to do with this. Debian's shipping the programs and the libraries together, more than merely aggregated -- so that the programs will load those specific libraries. The Debian install of vim includes big chunks of libc. So in answer to your direct question: the unlinked binary isn't derived from any of them. The complete binary, including its libraries, included whichever one Debian shipped it with. > The program vim contains a list of function names, all of which are > found in the ISO C standard, or in one of POSIX, SuS etc. It also > mentions a soname similar to libc.so.6. Please explain how that can > form a copy of libc. That doesn't. The actual copy of libc there on disk and loaded into memory does. The fact that the collection of programs {vim, emacs, tcsh} has had the common factor libc compressed out has nothing to do with it. > In the case of Java, the binding is even looser. A class might > contain references to other classes which the JVM is free to look for > anywhere it pleases. AFAIK, Eclipse uses only the standard Java API > as published by Sun, and will run equally well with any implementation > of said interface. Great -- which implementation does Debian ship it with? That's all that really matters. > This whole discussion is something between ridiculous and hilarious, > definitely not useful. If it causes even one person to understand that the generation or transportation of a copy is what matters, and not technical workarounds, I'll consider it useful. -Brian -- Brian Sniffen [EMAIL PROTECTED]