[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



On Fri, Jan 23, 2004 at 05:51:52PM +0300, Vladimir Prus wrote:
> 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?

The linking command you deleted above.

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

You didn't read what I said correctly.  The dlopened library will be
_dynamically_, not statically, linked with libc.  So you end up with a
static copy and a dynamic copy - boom.

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

It is for non-system libraries.  You are performing a dynamic link. 
-Bstatic -lfoo -Bdynamic is probably fine.  It's the trailing -Bstatic
and assuming what that will do to any implicitly linked libraries that
is illegal.

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

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer



Reply to: