Re: How to build the elf interpreter (ld-linux.so.2/ld-2.17.so) as static library?

["Carlos O'Donell" <carlos at redhat dot com>]

On 08/01/2013 02:17 AM, Borislav Peev wrote:
> On Thu, Aug 1, 2013 at 8:55 AM, Carlos O'Donell <carlos@systemhalted.org> wrote:
>> On Mon, Jul 29, 2013 at 7:24 AM, Borislav Peev <borislav.asdf@gmail.com> wrote:
>>> [Requesting program interpreter: /lib/ld-linux.so.2]
>>>
>>> I traced this library ld-linux-so.2 to be part of glibc. I am not very
>>> happy with this behaviour because it makes the binary very unportable
>>
>> It does not make the binary unportable.
>>
>> Distributions all agree upon the dynamic loader name for a
>> given target architecture.
>>
> 
> So it doesn't make the binary unportable among distributions which are
> in agreement. I see.

Correct.

> What if I want my distro to have something different and I do not
> agree with something?

You broke the ABI and you have to deal with the consequences.

> How could we ever improve if we agree with everything all the time?

Feel free to propose something new and provide patches to implement it.
 
>> What kind of portability are you looking for?
>>
> 
> The kind where you I'll be able to test a new concept for my distro
> without having to
> get into kernel development.

That sounds great, but you'll have to do kernel, glibc, and debugger
development before you can get to that place.
 
>>> - if I change the location of /lib/ld-linux.so.2 the executable no
>>> longer works and the only "fix" I found is to use the patchelf utility
>>
>> You can't change the location of the dynamic loader. It is part of the ABI.
>>
> 
> Yes I can, thus it is not part of the ABI. I changed it with pathelf
> and it works just fine.

You are wrong. It is part of the ABI.

> If it was part of the ABI it would be impossible to have different
> interpreter, for example uClibc.

That is not true. You can break the ABI very easily.

> I believe
> this makes sense. Just put the code that loads all .so-s at the start
> of main(), so it would load
> before everything else and then there wouldn't be any need for relying
> on paths. Maybe
> it is not possible at the moment with the current state of things, but
> it is certainly 1) possible
> 2) easy (for someone who knows about glibc/gcc/kernel better than
> myself) 3) binary compatible
> 4) more portable because it doesn't rely on agreement between infinite
> number of distros.

It does make sense. It isn't possible today.

Why not use `-static' (though you still need the runtime for dl* functions)?

It is possible to build sufficient infrastructure to not need to rely on
a path to the dynamic loader, but if you want to make the loader replaceable
at runtime (like the current system supports), you have to give the
dynamic loader some kind of label in order to identify it, and that's
equivalent to a path?

>> There are serious problems with linking statically.
> 
> Could you please elaborate on this one, because I am not aware of such
> problems. As far as I
> know statically linked executable will work forever in the same way as
> long as the ELF/PE/ETC
> format is supported by the OS, which is great if this is what you intend.

How do you repair defects in the dynamic loader if it's statically
linked into all of the applications?

http://www.akkadia.org/drepper/no_static_linking.html

Cheers,
Carlos.