[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 Sniffen                                       bts@alum.mit.edu

Reply to: