Re: Problem with GPLv3 FAQ about linking with Visual C++

[Alexander Terekhov]

Hyman Rosen wrote:
> 
> On 2/4/2010 4:35 PM, Alexander Terekhov wrote:
> > Resolving symbolic links (by a linker program) to something less
> > expressive (but more effecient) doesn't create a modified/derivative
> > work
> 
> You say "modified/derivative" as if the two words are
> synonyms, but they are not. A copy of library altered
> by a linker is "modified" and is not "verbatim" nor is
> it a copy of the "source". The technical meaning of
> "derivative" in copyright law is not the same as
> "modified". A book with a page ripped out is "modified"
> but not "derivative".

A statically linked 'executable' is NOT a book with a page ripped out
you moron.

http://en.wikipedia.org/wiki/Static_library

"In computer science, a static library or statically-linked library is a
set of routines, external functions and variables which are resolved in
a caller at compile-time and copied into a target application by a
compiler, linker, or binder, producing an object file and a stand-alone
executable. This executable and the process of compiling it are both
known as a static build of the program. Historically, libraries could
only be static.

Static libraries are either merged with other static libraries and
object files during building/linking to form a single executable, or
they may be loaded at run-time into the address space of the loaded
executable at a static memory offset determined at
compile-time/link-time.

There are several advantages to statically linking libraries with an
executable instead of dynamically linking them. The most significant is
that the application can be certain that all its libraries are present
and that they are the correct version. This avoids dependency problems.
In some cases, static linking can result in a performance improvement.
Static linking can also allow the application to be contained in a
single executable file, simplifying distribution and installation.

With static linking, it is enough to include those parts of the library
that are directly and indirectly referenced by the target executable (or
target library). With dynamic libraries, the entire library is loaded,
as it is not known in advance which functions will be invoked by
applications. Whether this advantage is significant in practice depends
on the structure of the library.

In static linking, the size of the executable becomes greater than in
dynamic linking, as the library code is stored within the executable
rather than in separate files. If you include the size of the library
files in the application then the total size will be similar. On
Microsoft Windows it is common to include the library files an
application needs with the application. On Unix-like systems this is
less common as package management systems can be used to ensure the
correct library files are available. This allows the library files to be
shared between many applications leading to space savings. It also
allows the library to be updated to fix bugs and security flaws without
updating the applications that use the library. These advantages are not
the sole consideration, and many executables (especially those targeting
Microsoft Windows) use both static and dynamic libraries.

It is important to note that any static library function can call a
function or procedure in another static library. The linker/linking
loader/loader handles this the same way as for any "normal" object file.

Static library files may also be linked/loaded at run-time by a linker
or linking loader (e.g., the X11 module loader). However, whether such a
process can be called static linking is controversial."

regards,
alexander.

--
http://gng.z505.com/index.htm 
(GNG is a derecursive recursive derecursion which pwns GNU since it can 
be infinitely looped as GNGNGNGNG...NGNGNG... and can be said backwards 
too, whereas GNU cannot.)