Bug#227906: libc6: Failed assertion in ld.so
On Tue, Jan 20, 2004 at 12:18:30PM +0300, Vladimir Prus wrote:
> 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.
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.
> 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...
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.
> 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.
> 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. 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.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
Reply to: