Re: Eclipse 3.0 Running ILLEGALY on Kaffe
Måns Rullgård <mru@inprovide.com> writes:
> 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?
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 bts@alum.mit.edu
Reply to: