This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

作者 skrah
收信人 akuchling, asmodai, mark.dickinson, r.david.murray, rpetrov, skrah
日期 2010-04-27.12:43:15
SpamBayes Score 2.0586373e-05
Marked as misclassified
Message-id <20100427124151.GA2620@yoda.bytereef.org>
In-reply-to <1272366262.94.0.354317270566.issue7384@psf.upfronthosting.co.za>
内容
Jeroen Ruigrok van der Werven <report@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 (via -ltermcap which is the same lib)
>   b) wide-character enabled ncurses, ncursesw.so, is also loaded in the same process
>
> To solve that, we need to have a separate termcap.so, do I understand the issue correctly?"

Yes, only that the separate termcap is called libtinfo.so. The approach of
splitting out libtinfo from ncurses (used by Fedora) is the most flexible
and allows the user to choose ncurses or ncursesw.

[stefan@fedora-amd64 ~]$ ldd /lib64/libreadline.so.6.0
        linux-vdso.so.1 =>  (0x00007fff725ff000)
        libtinfo.so.5 => /lib64/libtinfo.so.5 (0x00000036e4a00000)
        libc.so.6 => /lib64/libc.so.6 (0x00000036d9600000)
        /lib64/ld-linux-x86-64.so.2 (0x00000036d9200000)

+ports that use ncurses (ncurses and ncursesw are source compatible, but in most cases they are binary compatible as long as application don't
+assume size of ncurses structures)."
>
> Which I fully support, it's something that I did on DragonFly BSD a long time ago already (for all I can remember).
>
> Your opinion?

I think the libtinfo approach is more flexible, and I'm not aware of any drawbacks.
So, for FreeBSD, I'd use it.

Stefan Krah
历史
日期 用户 动作 参数
2010-04-27 12:43:25skrah修改recipients: + skrah, akuchling, mark.dickinson, asmodai, rpetrov, r.david.murray
2010-04-27 12:43:15skrah链接issue7384 messages
2010-04-27 12:43:15skrah创建