This is an echo of a bug report entered in Debian, since Mageia suffers from the same issue. Basically, by linking libreadline against libncurses, programs linking with libreadline are prevented from also linking with libncursesw, since doing so might produce crashes in certain conditions (witnessed under e.g. FreeBSD). This manifests concretely when building Python, which has both a curses binding module and a readline binding module. libncursesw has more features than libncurses (supports unicode better), so linking libreadline against libncursesw should *hopefully* (!) be a no-brainer ;) Original bug report at Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=602720 Quoted here: libncurses cannot be used to write "Unicode compliant" programs. Python 2.7 and 3.2 refuse to link its curses module to libncursesw if libreadline is linked to libncurses, because it causes a segfault on FreeBSD. For Python 3.2, libncurses is a problem because Python 3 tries to be fully unicode compliant. More information in the following Python bug reports: * (open) curses: Link against libncursesw instead of libncurses http://bugs.python.org/issue9408 * (closed) curses crash on FreeBSD http://bugs.python.org/issue7384 Comment of #9408 by Stefan Krah: "Actually the distros should either link readline against libtinfo (Fedora) or only use ncursesw (DragonFly)." So would it be possible that libreadline is linked to libncursesw instead of libncurses?
CC: (none) => misc
Yep, should be doable in cauldron. Now, I would rather wait before backporting the fix on stable ( as it could have unintended side effects :/ )
(In reply to comment #1) > Yep, should be doable in cauldron. Now, I would rather wait before backporting > the fix on stable ( as it could have unintended side effects :/ ) Agreed, this is really a wish rather than a bug, and there's no point risking breakage by backporting it.
CC: (none) => stormiVersion: 1 => Cauldron
(In reply to comment #1) > Yep, should be doable in cauldron. @ misc No maintainer, are you willing to do this?
CC: (none) => mageia, marja11
Assign this bug to barjac
CC: (none) => n54
He is working with this package https://bugs.mageia.org/show_bug.cgi?id=3053#c8
@misc I recently tried to re-build readline (after fixing a doc permission) and it won't now build against libncursesw. It does build OK against libncurses. Any ideas?
Yes. Start with the spec, for example here: %build export LDFLAGS="-I%{_includedir}/ncurses -lncurses" export CFLAGS="%{optflags} -I%{_includedir}/ncurses -lncurses" export CXXFLAGS="%{optflags} -I%{_includedir}/ncurses -lncurses" use ncursesw for -I and -l
@ Barry Do you agree on having this bug assigned to you?
CC: (none) => zen25000
(In reply to comment #8) > @ Barry > > Do you agree on having this bug assigned to you? Yes - done
Assignee: bugsquad => zen25000
Well, when you mean "don't build", what does it say ?
Created attachment 1212 [details] build log (In reply to comment #10) > Well, when you mean "don't build", what does it say ? Sorry - I should have been more specific. Build log attached. I think Kamil hit the nail on the head in #7. Replacing all instances of ncurses with ncursesw in those lines fixes the build in iurt. As you made the original switch from ncurses to ncursesw I would appreciate you reviewing the current spec in svn before I submit it. http://svnweb.mageia.org/packages/cauldron/readline/current/SPECS/readline.spec?view=markup
It would have been better to document all change, ( and avoid to do some live move without telling in the changelog, because this make review harder ) After a quick look, I think the spec was buggy in the first place, '-lncurses' doesn't really belong to CFLAGS, since that's a linker option. And I see no one commented the patches, which sadden me a little as usual, but I guess none of these prevent the package from being shipped since it build fine. I also guess that we should investigate a proper fix to send it upstream so we do not have to fiddle with $CFLAGS :/ have you tried to build in iurt without touching to CFLAGS, maybe this work fine ?
(In reply to comment #12) > I also guess that we should investigate a proper fix to send it upstream so we > do not have to fiddle with $CFLAGS :/ > have you tried to build in iurt without touching to CFLAGS, maybe this work > fine ? Good thought - it builds OK in iurt with only the LDFLAGS touched - so I'm removing the other two. I am a little concerned about it's Require on libncurses-devel - should that also now be changed to libncursesw-devel ?
Blocks: (none) => 3053
OK, pushed in Cauldron with the changes. Closing as fixed - please re-open if this causes any issues.
Status: NEW => RESOLVEDResolution: (none) => FIXED