Stefan Krah stefan-use...@bytereef.org added the comment:
ldd return value check committed in r82927, r82928, r82929 and r82930.
Thanks for reporting this!
--
status: open - closed
___
Python tracker rep...@bugs.python.org
Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com added the comment:
This patch allows to build Python 3.* in this locale.
It might be safer to open tmpfile in binary mode to avoid potential problems
with non-ASCII characters in paths to libraries.
--
Stefan Krah stefan-use...@bytereef.org added the comment:
So you have garbage from stderr in readline_termcap_lib. Since that's
useless anyway (no matter what locale is set), let's check the return
value of os.system().
The attached patch skips readline linkage detection if ldd fails. In
that
Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com added the comment:
These changes break building of Python 3.* in some locales in Gentoo.
running build
running build_ext
Traceback (most recent call last):
File ./setup.py, line 1812, in module
main()
File ./setup.py, line 1807,
Stefan Krah stefan-use...@bytereef.org added the comment:
In Ubuntu I can build just fine with lt_LT.UTF-8. So perhaps this problem
should be addressed in Gentoo.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7384
Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com added the comment:
You shouldn't use ldd. I suggest that setup.py try to link a small executable,
which would use a function from libcurses and would be linked against
libreadline, but not libcurses. If linking succeeds, then you
STINNER Victor victor.stin...@haypocalc.com added the comment:
In lt_LT.UTF-8 locale, readline_termcap_lib file contains:
ne dinaminis paleidžiamasis failas
You can run ldd without LANG variable to get the original (english, ascii only)
message.
--
Stefan Krah stefan-use...@bytereef.org added the comment:
Committed a conservative version implementing part 1) in r82017 (2.6) and
r82019 (3.1). Part 2) can be enabled by uncommenting a couple of lines in
setup.py.
The buildbots look good, but I'm setting this to 'pending' in case
someone
Stefan Krah stefan-use...@bytereef.org added the comment:
Committed in r81669,r81672,r81683 (trunk) and r81830,81831 (py3k).
What to do with the releases? To recap, the fix is:
1) Detect if readline is already linked against ncurses and
if so, skip any further selection. This must be
Stefan Krah stefan-use...@bytereef.org added the comment:
I think it would be nice to get this into 2.7. I don't expect buildbot
failures, since the 2.7 patch is essentially the same as the py3k version,
which has been tested extensively.
--
Added file:
Mark Dickinson dicki...@gmail.com added the comment:
I think it would be nice to get this into 2.7.
Agreed. I think you should go ahead and commit it.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7384
Stefan Krah stefan-use...@bytereef.org added the comment:
Mark, thanks. Committed in r81669; I'll keep an eye on the buildbots.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7384
___
STINNER Victor victor.stin...@haypocalc.com added the comment:
I tested issue7384-5-py3k.patch on FreeBSD 8.0: it fixes the crash.
--
nosy: +haypo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7384
Stefan Krah stefan-use...@bytereef.org added the comment:
Roumen Petrov rep...@bugs.python.org wrote:
Yes , I understand .
For the protocol did gcc on FreeBSD warn if library order is -lncursesw
-lreadline ?
No.
P.S. Issue with readline library linked to termcap compatible library on
Jeroen Ruigrok van der Werven asmo...@in-nomine.org added the comment:
Stefan, I was emailing with Rong-En Fan, a FreeBSD committer, about this issue
and he asked:
Basically, this is caused by
a) our readline.so is linked against ncurses.so (via -ltermcap which is the
same lib)
b)
Stefan Krah stefan-use...@bytereef.org added the comment:
Jeroen Ruigrok van der Werven rep...@bugs.python.org wrote:
Stefan, I was emailing with Rong-En Fan, a FreeBSD committer, about this
issue and he asked:
Basically, this is caused by
a) our readline.so is linked against ncurses.so
Roumen Petrov bugtr...@roumenpetrov.info added the comment:
Yes , I understand .
For the protocol did gcc on FreeBSD warn if library order is -lncursesw
-lreadline ?
Forget for
Also I'm not able to write C test case similar to python msg103231 by
Mark Dickinson that fail on system where
Stefan Krah stefan-use...@bytereef.org added the comment:
I included the test for libtinfo in the latest patch. The patch is tested
on Fedora and correctly links the curses module with -lncursesw.
This means that the ldd method works on all buildbots, OpenBSD, OpenSolaris
and Fedora.
Stefan Krah stefan-use...@bytereef.org added the comment:
I'm not against sorting things out in configure.in, but I'm not quite
sure that it will be more portable than ldd:
On FreeBSD (the problem system!) I can't get this to work:
[ste...@freebsd-i386 ~]$ echo 'int main() { readline(); }'
Stefan Krah stefan-use...@bytereef.org added the comment:
Sigh. xxx.c == test_readline.c in the previous comment.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7384
___
Stefan Krah stefan-use...@bytereef.org added the comment:
Mark, thanks for reviewing the patch. In the new patch, I added a skip
for OS X.
Buildbot testing looks good. In particular, one FreeBSD bot passes
test_curses now (the other one is hanging in multiprocessing).
For most bots nothing
Jeroen Ruigrok van der Werven asmo...@in-nomine.org added the comment:
I did some digging on my side, the fact you see ncurses referenced from
readline is due to the build linking readline to libtermcap:
cc -fstack-protector -shared -Wl,-x -o libreadline.so.8
-Wl,-soname,libreadline.so.8
Stefan Krah stefan-use...@bytereef.org added the comment:
Yes, readline uses only the termcap part of ncurses. I think that
--with-termlib is the correct option, see:
http://www.mail-archive.com/util-linux...@vger.kernel.org/msg00273.html
--
___
Stefan Krah stefan-use...@bytereef.org added the comment:
Actually this means that we should also look for -ltinfo in the ldd
check (A Redhat buildbot would be nice).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7384
Roumen Petrov bugtr...@roumenpetrov.info added the comment:
Roumen, I do not see a line in configure.in that tests for the
libraries that readline is linked against.
The test in configure is how to link application to readline libs.
Platforms that support linking of shared libraries with
Roumen Petrov bugtr...@roumenpetrov.info added the comment:
Stefan Krah wrote:
Stefan Krahstefan-use...@bytereef.org added the comment:
Actually this means that we should also look for -ltinfo in the ldd
check (A Redhat buildbot would be nice).
Or may be this mean that in configure to add
Roumen Petrov bugtr...@roumenpetrov.info added the comment:
Instead to test in setup.py we could use result from configure script - just
uncomment line and use it
--
nosy: +rpetrov
___
Python tracker rep...@bugs.python.org
Stefan Krah stefan-use...@bytereef.org added the comment:
Jeroen, thanks for the idea. I asked Thomas Dickey and he said that
one should not load both libncurses.so and libncursesw.so.
I think this means that if libreadline.so is already linked against
libncurses.so, we are stuck with
Mark Dickinson dicki...@gmail.com added the comment:
This patch looks good to me, assuming that the buildbots are happy. I agree
that this seems like a sensible solution for now, even if it means limiting
users to ncurses rather than ncursesw.
I was initially a bit surprised that it works on
Jeroen Ruigrok van der Werven asmo...@in-nomine.org added the comment:
Just to state the obvious: ncursesw is needed for wide character support (i.e.
Unicode).
Also, have you tried asking Thomas Dickey (dic...@invisible-island.net) about
this? He might be able to give some clue about it since
Stefan Krah stefan-use...@bytereef.org added the comment:
One oddity: In Mark's test case, the error only shows if readline
is imported _before_ curses. The other way around it's fine.
On FreeBSD 8.0 amd64, with the _default_ libcurses, the Valgrind output
for py3k looks like this:
[...]
Stefan Krah stefan-use...@bytereef.org added the comment:
I take that back. With the curses from /usr/ports/devel/ncurses,
Mark's test case is fine, but
./python Lib/test/regrtest.py -uall test_curses
fails again.
--
___
Python tracker
Stefan Krah stefan-use...@bytereef.org added the comment:
Alas, after installing curses from /usr/ports/devel/ncurses I did not
recompile Modules/_curses_panel.c.
So, after a proper build
./python Lib/test/regrtest.py -uall test_curses
shows no errors.
--
Stefan Krah stefan-use...@bytereef.org added the comment:
It seems that FreeBSD has problems with the fact that readline.so is
linked with -lreadline and -lncursesw (why?).
With issue7384.patch I get no more errors using either Mark's test case
or test_curses.py.
--
Added file:
Mark Dickinson dicki...@gmail.com added the comment:
That patch works for me, too. Nice!
It seems that FreeBSD has problems with the fact that readline.so is
linked with -lreadline and -lncursesw (why?).
Good question...
--
___
Python tracker
Jeroen Ruigrok van der Werven asmo...@in-nomine.org added the comment:
For the record, this happens on FreeBSD 8 as well.
It seems it is still the same bug as what I reported back in March 2009 on the
Python-dev list.
If you run the test stand-alone with ./python Lib/test/regrtest.py -uall
Mark Dickinson dicki...@gmail.com added the comment:
Mark, did your initial backtrace look like this:
No; the segfault was definitely happening in delwin rather than putwin. But I
did see something like your backtrace when I tried to use ncurses from ports
(installed in /usr/local) rather
Stefan Krah stefan-use...@bytereef.org added the comment:
Valgrind can be installed by:
cd /usr/ports/devel/valgrind make install
Then you can do (curses_test.py is your short test program):
1) valgrind --db-attach=yes --suppressions=Misc/valgrind-python.supp ./python
curses_test.py
2)
Mark Dickinson dicki...@gmail.com added the comment:
I'm looking at this again, after installing FreeBSD 8.0/amd64 in a VM.
I've reduced Lib/test/test_curses.py to the following 9 lines:
import rlcompleter
import curses
f = open('mytempfile', 'w+b')
stdscr = curses.initscr()
stdscr.putwin(f)
Mark Dickinson dicki...@gmail.com added the comment:
Here's the top of the backtrace. (Thanks asmodai for helping me out with
working out how to build a FreeBSD system ncurses with debugging information.)
#0 0x000801460714 in cannot_delete (win=0x80116b1d0)
at
A.M. Kuchling li...@amk.ca added the comment:
Could I get a login on the buildbot to make a fix?
I bet the problem is with the stdscr object. PyCurses_InitScr()
does 'return (PyObject *)PyCursesWindow_New(stdscr);'.
PyCursesWindow_Dealloc() does:
if (wo-win != stdscr) delwin(wo-win);
I bet
A.M. Kuchling li...@amk.ca added the comment:
Here's a possible patch; it at least doesn't seem to break the module on MacOS,
though MacOS doesn't crash with the current code either.
--
keywords: +patch
Added file: http://bugs.python.org/file16935/freebsd-curses.diff
Mark Dickinson dicki...@gmail.com added the comment:
Could I get a login on the buildbot to make a fix?
I think David Bolen (db3l) is the maintainer. David?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7384
Mark Dickinson dicki...@gmail.com added the comment:
Here's a possible patch
Thanks. I'll give it a try on my FreeBSD VM and report back.
BTW, did you mean to include the threading change in that patch?
--
___
Python tracker rep...@bugs.python.org
Changes by Jeroen Ruigrok van der Werven asmo...@in-nomine.org:
--
nosy: +asmodai
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7384
___
___
Mark Dickinson dicki...@gmail.com added the comment:
With that patch, I'm still getting the core dump (with the traceback looking
pretty much as it did before).
When I traced through this with gdb, I didn't see stdscr getting set to 0 at
any point. Unless I missed any, the only curses
Mark Dickinson dicki...@gmail.com added the comment:
It does appear that curses itself is broken on FreeBSD
Rereading this, it doesn't say what I meant it to say: I meant that the Python
curses module seems to be broken, not that the system-level curses library is
broken (though that seems
Mark Dickinson dicki...@gmail.com added the comment:
I've not had any success tracking the cause of this failure down, and no longer
have the resources to do so. It does appear that curses itself is broken on
FreeBSD: it's not just a problem with the tests.
Adding Andrew Kuchling to the
R. David Murray rdmur...@bitdance.com added the comment:
Given your diagnosis so far, +1 on the skip.
--
nosy: +r.david.murray
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7384
___
49 matches
Mail list logo
