This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.
What if I want my distro to have something different and I do not
agree with something?
How could we ever improve if we agree with everything all the time?

> 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.


>> - 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.
If it was part of the ABI it would be impossible to have different
interpreter, for example uClibc.

If you actually read the question it is how to statically link the
dynamic loader. 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.

> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]