[uClibc] Re: dyn lib dependency question

Peter S. Mazinger ps.m at gmx.net
Tue Nov 16 09:46:30 UTC 2004


On Tue, 16 Nov 2004, Erik Andersen wrote:

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

strings libreadline.so.4 has reference to tgetent (coming from ncurses), 
so Jocke is right saying that the readline-4.x package has to be rebuilt 
correctly.

I will try to rebuild readline w added -lncurses and see if then python 
can be built (probably yes)

This bug became visible after changes to uclibc-cvs-20041018 (on that date 
I have a python build that succeeded)

Peter

-- 
Peter S. Mazinger <ps dot m at gmx dot net>           ID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08  BB6E C389 975E A5F0 59F2




More information about the uClibc mailing list