Bug#227906: libc6: Failed assertion in ld.so
Daniel Jacobowitz wrote:
> > > I have no idea if that is possible. I don't think that it is. If you
> > > link to libc.a, then you will not have an initialized dynamic loader,
> > > and shared libraries will not be properly loaded.
> > Okay. The problem, then, is that libc docs never mention this problem.
> It's just an assumption. Dynamic linking can not work unless the
> dynamic loader is dynamically linked. Honestly, I have no idea what
> the output of that command is going to look like.
Of which command?
> > Which talks about 'dlopen', I guess. In fact, when I try 'dlopen'ing
> > lib.so, rather than linking to it, everything works, except for the
> > following warning:
> > /tmp/x/app.cpp:9: warning: Using 'dlopen' in statically linked
> > applications requires at runtime the shared libraries from the glibc
> > version used for linking
> > So, I've three questions:
> > 1. Why is it so that 'dlopen' works but direct linking does not. I though
> > they use the same mechanism...
> They don't :) They share a lot of common code, but that's not the same
> thing. Dynamic linked libraries participate in symbol resolution, for
Ok... though I still don't understand what problem prevents dynamic linking
when you have static libc :-(
> > 2. Why 'dlopen' in static application requires shared libc?
> The shared library you open, if it is correctly built, will reference
> shared libc.so.6, causing libc.so.6 to be dlopen'd into your
> application. If it mismatches the included version of glibc unknown
> things will happen, and in the past, have happened.
OTOH, I the library is built with static libc, there's no problem. Of course,
unless two statically linked copies of libc will decide to have a fight --
and I don't know if they will.
> > 3. Should not the docs say that static linking to libc is not possible if
> > any dynamic libraries are used?
> If you had just statically linked to libc, then the result might have
> been different. Playing with -Bstatic in this way is not a good way to
> accomplish it.
So, essentially -Bstatic is not suitable for selecting between static and
dynamic versions of given library?
> Try adding a libc.so script in an -L directory, like
> the existing one, but which references libc.a instead of
> libc_nonshared.a and libc.so.6. I have no idea what that will cause to
> happen, either.
collect2: ld terminated with signal 11 [Segmentation fault]
I think I probably should give up, and agree that even though libc probably
should not assert, I'm not using it in documented way, either.