Bug#227906: libc6: Failed assertion in ld.so

[Vladimir Prus <ghost@cs.msu.su>]

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

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.

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

- Volodya