Re: Use of GPL'd code with proprietary programs

[David Kastrup]

hollaar@faith.cs.utah.edu (Lee Hollaar) writes:

> David Kastrup <dak@gnu.org> writes:
> >hollaar@faith.cs.utah.edu (Lee Hollaar) writes:
> >
> >> David Kastrup <dak@gnu.org> writes:
> >> >cstacy@news.dtpq.com (Christopher C. Stacy) writes:
> >> >> I think you may have misspoken in the above paragraph, because
> >> >> "dlopen" _is_ dynamic linking.
> >> >
> >> >man dlopen.  No symbols are resolved by dlopen in the caller.
> >> 
> >> man dlopen.  From the header on every page, at least on my system:
> >> "Dynamic Linking Library Functions                     dlopen(3DL)"
> >
> >That must be about the most relevant part of a manual page imaginable.
> 
> Perhaps it gives some idea about what the creators of dlopen(),
> dlsym(), and dlclose() thought their purpose was.  Or maybe people
> guess that from the "dl" at the start of each function name.  (Hint:
> it probably doesn't stand for "dumb luck".)
> 
> Or maybe not everybody agrees with your particular definition of
> what dynamic linking requires ...

Or maybe, if you stop being so dense and actually care to read the
manual pages, you'll notice that dlopen resolves symbols (to other
libraries) in the _loaded_ library and thus the _caller_ remains
unchanged, like I said.

In the case of dynamically linking a program, it is not the program
that does the linking.  Instead ld-linux.so links the program,
entering the dynamic library symbol information into it, _before_
chaining to the linked program.

A program can't cause linking of itself by calling dlopen because an
unlinked program is unfit for running.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum