Hi Olaf,

On 13/03/14 14:50, Olaf Walter wrote:
Hi Kenneth,

So, it seems like somehow telling Python to also link with "-lncurses"
should resolve the issue.
How can I do this? Just mentioning ncurses in the dependencies seems not to be 
enough.
I'm working on a proper fix.

Python automagically tries to link to libreadline as follows:

checking how to link readline libs... -lreadline -lncursesw

Right now, the libncurses built with EasyBuild doesn't provide libncursesw.so (or .a).

I'm trying to see whether making sure that they are there fixes the problem.

I'll let you know once I've figured things out, and we'll enhance the sanity checks included in the Python easyblock to capture this problem earlier. It's easy to check: if "import readline" doesn't work, stuff is broken...


regards,

Kenneth



I tried Pablo's approach using the RPMs and it solves the issue in Python, but 
not in IPython. I would prefer to solve this within easybuild, but it's too 
puzzling.

The IPython build fails, with a similar error message:

== 2014-03-13 14:16:30,691 main.run INFO parse_log_for_error msg: Command used: 
iptest
== 2014-03-13 14:16:30,692 main.run INFO parse_log_for_error (some may be 
harmless) regExp (?<![(,-]|\w)(?:error|segmentation 
fault|failed)(?![(,-]|\.?\w) found:
ERROR: Test we're not loading modules on startup that we shouldn't.
ValueError: Running file '/tmp/easybuild-9LI3g5/tmpvba19N.py' produced error: 
'WARNING: Readline services not available or not loaded.\nWARNING: The 
auto-indent feature requires the readline library\n'

Did anybody get IPython working with readline?

Best regards,
Olaf

-----Ursprüngliche Nachricht-----
Von: [email protected] [mailto:[email protected]] 
Im Auftrag von Kenneth Hoste
Gesendet: Donnerstag, 13. März 2014 11:03
An: [email protected]
Betreff: Re: [easybuild] Python and readline


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

Reply via email to