On 13/03/14 10:54, Fotis Georgatos wrote:
Hello *,
On Mar 13, 2014, at 9:34 AM, Kenneth Hoste wrote:
*** WARNING: renaming "readline" since importing it failed:
/path/to/software/libreadline/6.2-goolf-1.4.10/lib/libreadline.so.6: undefined symbol: PC
hey, that rings a bell:
* ncurses is an -optional- dependency of libreadline;
and when not explicitly declared the above message appears.
I have noticed at least two round of discussions over the last 12 months as
regards the matter;
fi. last summer's EB-provided libreadline builds are supposed to have the dep
defined (July 2013);
*plenty* of software sits atop libreadline so that has far-reaching (and
build-silent) effects;
In fact, this is a prime example why having *buildsets* to fight sw temporal
divergence is a MUST.
I hope others can confirm that the above is on-topic hint.
I've been looking into this a bit more, and it's indeed ncurses who's to
blame.
It's even worse... As far as I can tell, libreadline never links to
ncurses itself, even though the libreadline.so|a libraries use symbols
provided by ncurses.
The idea is that users are left free to chose whether they use ncurses
or termcap to provide the symbols.
Result: if you don't link with "-lreadline -lncurses", and e.g. use
"-lreadline", you can run into problems like this.
So, it seems like somehow telling Python to also link with "-lncurses"
should resolve the issue.
Now, what really puzzles me is:
1) Why does this problem only occur with Python 2.7.5 and 2.7.6? Python
2.7.3 seems to be fine...
2) Why didn't we notice this earlier? :(
regards,
Kenneth
