Re: rtld + static linking

On Thu, Nov 27, 2003 at 03:41:14AM -0800, Terry Lambert wrote:

> > If you can get gcc and binutils to add the necessary support, then
> > we can talk further. Until then it's academic.
> 
> I think there are political reasons for not doing this.  The
> number one reason would be that you could load GPL'ed code as
> a module into a non-GPL'ed program, and then use it without
> neding to change your own license to GPL.

The use of dlopen() does not circumvent that you're creating a
modified version. The GPL-incompatible code and the GPL code do
not communicate at arms length. Hence, the GPL-incompatible code
is to be relicensed if the modified work is to be distributed.i
Alternatively, ask the license holder for an exception or see if
the library can be relicensed under the LGPL.

>From a GPL licensing point of view dlopen() is no different than
static linking.

> > > I'll also point out that the ELF specification does not define static
> > > linking *at all*.
> > 
> > I think that's because it doesn't need any special mention.
> 
> Well, it specifically mentions being able to do something like
> linking libc to libresolv, so that you implicitly get the resolver
> library when you explicitly link in the C library. That doesn't
> work with static linking of ELF binaries, so I think we can either
> say static linking is completely broken and needs to be fixed before
> it is allowed to be used, or static linking is undefined by the ELF
> standard.

Recording dependencies in ELF files is specific to dynamic linking.
In fact, there's nothing that you need to add to ELF headers or
sections to make static linking work. It's irrelevant to an ELF
specification. That's why it's not mentioned. Dynamic linking needs
special headers and/or sections in the ELF file to make it work.

I don't think you can infer from the ELF specification that static
linking is undefined.

-- 
 Marcel Moolenaar	  USPA: A-39004		 marcel_at_xcllnt.net