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

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

Daniel Jacobowitz wrote:

> > > > >    g++ -o lib.so -shared -static-libgcc lib.cpp -Wl,-Bstatic
> > > > >    g++ -o app app.cpp lib.so -static-libgcc -Wl,-Bstatic
> > >
> > > What is this trying to accomplish?  You're going to get shared
> > > versions of some libraries and dynamic versions of others.
> >
> > This is trying to get static version of all "runtime" libraries: such as
> > libstd++, libc and libgcc, but link to dynamic lib.so
>
> 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.
In fact, I could find only the following:

    .... since not many platforms support dynamic
    loading in statically linked programs.  On platforms without this
    capability it is therefore not possible to use this interface in
    statically linked programs.  The GNU C library has, on ELF platforms, no
    problems with dynamic loading in these situations; therefore, this
    point is moot.

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

2.  Why 'dlopen' in static application requires shared libc? 

3. Should not the docs say that static linking to libc is not possible if any 
dynamic libraries are used?

TIA,
Volodya