[uClibc] Re: dyn lib dependency question

Joakim Tjernlund joakim.tjernlund at lumentis.se
Tue Nov 16 09:02:05 UTC 2004


> On Tue Nov 16, 2004 at 09:25:36AM +0100, Joakim Tjernlund wrote:
> > hmm, just to be clear. Python builds a lib called readline.so, this
> > lib depends on libncurses.so and libreadline.so. dlopening readline.so
> > will load both libncurses.so and libreadline.so, but when libreadline.so
> > wants to relocate the tgetent symbol, dlopen will fail because libncurses.so
> > is not in libreadline.so's dependency list.
> > 
> > I think the purpose of pythons readline.so is to pull libncurses.so in. If 
> > libreadline.so had the correct dependencies, readline.so would not exist.
> > 
> > Still consider this to be a bug in libreadline? I do.
> > 
> >  Jocke
> 
> If python's readline.so needs the symbol 'tgetent' but lacks a
> DT_NEEDED entry for a library providing 'tgetent' such as
> ncurses, then yes, regardless of usage, python's readline.so is
> broken.

No, it is libreadline.so that needs tgetent. This is why
pythons readline.so loads both libncurses.so and libreadline.so so
that libreadline.so should be able to find the tgetent symbol.

> Using dlopen to try and serendipitously score with some
> random symbol not in the library's needed chain just isn't
> sufficient.  If a library needs a symbol such as 'tgetent', then
> it also needs to use DT_NEEDED to let us know where it expects
> that symbol to be found.  If we give it everything it explicitly
> asks for, it is no longer our problem if it doesn't work.

Yes I agree. I just want to make sure uClibc's libdl does the right thing.

Glibc will of course allow python's readline.so magic, but that does not
make it right.

 Jocke



More information about the uClibc mailing list