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