Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 78313 - ncurses and the unicode USE flag, disabling unicode kills system
Summary: ncurses and the unicode USE flag, disabling unicode kills system
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: All Linux
: High critical (vote)
Assignee: Gentoo's Team for Core System packages
Depends on:
Reported: 2005-01-17 00:02 UTC by Ryan Hill (RETIRED)
Modified: 2005-03-25 05:36 UTC (History)
4 users (show)

See Also:
Package list:
Runtime testing required: ---

Patch for warning user when emerging ncurses without unicode USE flag (unicode.patch,794 bytes, patch)
2005-03-22 09:30 UTC, Alexander Simonov
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Ryan Hill (RETIRED) gentoo-dev 2005-01-17 00:02:11 UTC
yes, this should look familiar.  reference bug #64773, bug #74130, and bug #75927.  also reference

emerging a system with unicode in the USE flags and later removing it will kill the system upon the recompilation of ncurses, due to the removal of /lib/

the workaround is to symlink /lib/ to /lib/ and run revdep-rebuild

although this has been declared "NOTABUG", i think it's easy enough to put up a little safety tape to keep people from falling in too easily.  i suggest either:

a) an ewarn advising the user of the above workaround.  this non-bug is particularily nasty in that it kills nearly everything, including ls, gcc, links, firefox, etc.  this makes it very hard for a user to recover if they don't have a secondary access point to the net to look for an answer.  the downside to this is, unless i'm mistaken, it would have to be displayed every time any user emerged ncurses with -unicode, since portage can't 'detect' if the previous merge was done with unicode or not.

b) create the symlink regardless of unicode support. seems to indicate this may work, but i don't have the knowledge to confirm or deny that, or what side-effects it may have.  for what it's worth, the following code already exists in the ncurses ebuild:

    if use unicode ; then
        gen_usr_ldscript || die "gen_usr_ldscript failed"
        gen_usr_ldscript || die "gen_usr_ldscript failed"
        for i in ${D}/usr/$(get_libdir)/*w.*; do
            local libncurses=${i/${D}/}
            dosym ${libncurses} ${libncurses/w./.}
        for i in ${D}/$(get_libdir)/*; do
            local libncurses=${i/${D}}
            dosym ${libncurses} ${libncurses/w./.}
        # bug #4411
        gen_usr_ldscript || die "gen_usr_ldscript failed"
        gen_usr_ldscript || die "gen_usr_ldscript failed"

which seems to support the feasibility of this option.


Reproducible: Always
Steps to Reproduce:
Comment 1 SpanKY gentoo-dev 2005-01-17 15:03:32 UTC

*** This bug has been marked as a duplicate of 75927 ***
Comment 2 Ryan Hill (RETIRED) gentoo-dev 2005-01-17 15:39:36 UTC
no offense intended, but these are two completely different issues.

the bug you marked this as a duplicate of is about a compilation error that shows up emerging ncurses with unicode enabled.  this bug is about a system error that happens after emerging ncurses with unicode disabled.

if anything, this could be a dup of bug #64773, but that bug wasn't fixed, just marked a dup of bug #63594 which again has nothing to do with this.
Comment 3 Bob 2005-01-17 18:25:41 UTC
I have also been trapped by this problem.  In contrast to the explanations that have been offered before, I can verify that this is not a duplication.

I have *never* used the unicode USE flag on my system.  I do have the userlocales set as a local cflag for glibc in package.keywords, though.

I ran into this problem today while performing an emerge -uD system which caused me to pick up GCC (as a replacement for 3.4.3-r1) and ncurses-5.4-r5.  

i ran into the problem simply by emerging a new ebuild without changing any use flags -- this appears to be an ebuild problem, not a problem attributable to reconfiguration of one's system.
Comment 4 Ryan Hill (RETIRED) gentoo-dev 2005-01-17 20:08:03 UTC
i'd send it back to core, but i think vapier would squash my head. o_O

let's see what the UTF ppl think.
Comment 5 Alexander Simonov 2005-01-28 13:09:10 UTC
I think problem in ncurses install procedure.
Then user add into USE unicode flag then he having some big troubles.
Some programs (I don't have any thinks why?) using not*) 
This program using*).
And then user delete unicode from USE and rebuild ncurses (but why? may be
using emerge -e system ) he has trouble with this some programms.
I think we may remove unicode flag from ncurses and always build ncurses with unicode. Or remove symlinks of*) and using only*)
on unicode and on not unicode system. I think last way it's bad becouse we MUST
rewriting some ebuilds.
Comment 6 SpanKY gentoo-dev 2005-02-12 21:32:29 UTC
utf team: ncurses should probably be updated to work like redhat ... we should always build the normal ncurses library and if USE=unicode, additionally build the wide ncurses library ...
Comment 7 Vladimir Berezniker 2005-02-19 16:35:41 UTC
I just got bit by the same thing. Bunch of packages broke because ls could not be loaded due to the missing library.

First, I did the symlink workaround and then rebuilt coreutils.  Past that point I was able to delete the symlink and procede to rebuild other broken packages without any workarounds.

So the problem seems to be: the requirement for working ls in order to compile coreutils package, that contains ls source code.  The solution would be to make sure ls is not necessary to built coreutils package.

Comment 8 Alexander Simonov 2005-03-22 09:30:42 UTC
Created attachment 54161 [details, diff]
Patch for warning user when emerging ncurses without unicode USE flag

Add warning and beep when emerging ncurses without unicode USE flag
Comment 9 Heinrich Wendel (RETIRED) gentoo-dev 2005-03-22 09:56:37 UTC
the ebuild should check if previous versions are installed with unicode, to do so i'd check the existance of /usr/lib/
Comment 10 Alexander Simonov 2005-03-22 10:29:44 UTC
--- ncurses-5.4-r5.ebuild       2005-03-22 14:53:51.651185552 +0200
+++ ncurses-5.4-r5.ebuild.patched       2005-03-22 14:53:45.477124152 +0200
@@ -15,7 +15,29 @@
 DEPEND="gpm? ( sys-libs/gpm )"
+warning() {
+       ebeep
+       ewarn
+       ewarn "If you're have already ncurses with unicode USE flag that it may brake you system!"
+       ewarn "This non-bug is particularily nasty in that it kills nearly everything, including "
+       ewarn "ls, gcc, links, firefox, etc."
+       ewarn "If you want continue then set the COMPILE_NCURSES variable to TRUE!"
+       ewarn
+       epause 5        
 src_unpack() {
+       # check for unicode use flag
+       # See #78313
+       if use !unicode && [ -f /usr/lib/ ]; then
+               if [ "$COMPILE_NCURSES" != "TRUE" ]; then
+                       warning
+                       die "It's NOTABUG! SEE WARN BELOW!"
+               else 
+                       warning
+               fi
+       fi
        unpack ${A}
        cd "${S}"
        epatch "${FILESDIR}"/${P}-xterm.patch
Comment 11 Heinrich Wendel (RETIRED) gentoo-dev 2005-03-22 10:49:18 UTC
i modified the patch a bit and applied it, the function is the same
Comment 12 SpanKY gentoo-dev 2005-03-22 19:36:04 UTC
ok, that is not satisfactory
Comment 13 SpanKY gentoo-dev 2005-03-22 21:01:26 UTC
ive added 5.4-r6 which does what i suggested earlier ... it installs 'normal' ncurses and 'wide' ncurses when USE=unicode just like debian and redhat do
Comment 14 Heinrich Wendel (RETIRED) gentoo-dev 2005-03-22 23:03:41 UTC
and what's the benefit of that, that does not fix this problem
Comment 15 Ryan Hill (RETIRED) gentoo-dev 2005-03-23 21:21:24 UTC
the problem is when a program links to the 'wide' ncurses library, and then emerges ncurses without unicode, that library is replaced with the new one and your system goes bye-bye.  this happens with other packages too of course - i ran into it with LVM and dev-mapper last month - what makes this so critical are the packages that links to the wide ncurses library, including coreutils, bash, python, util-linux, dialog, less, and others.  in fact, the only reason i was able to recover the system at all was that i had slocate and was able to puzzle it out by trial and error.

that said, i don't know what a good solution would be.  but in this case i have to ask, how detrimental would it be to unconditionally force unicode in ncurses?  ie. remove the USE flag and just /always/ build ncurses with unicode support.  is there a downside to that, performance, stability, or user-wise?
Comment 16 SpanKY gentoo-dev 2005-03-25 00:07:32 UTC and have different ABI ... simply linking them may work most of the time (as was the old behavior), but it certainly is not correct

plus, you don't allow for a downgrade path for people who find that unicode support in curses isn't for them

if ncurses is installed with both the narrow and wide versions (as is the new behavior), then you should be able to control which version packages link against

so here's a "typical" use case:
export USE=unicode
emerge ncurses nano coreutils # <- nano and /bin/ls link with
< play around for a while, decide they dont want unicode >
export USE=-unicode
emerge nano coreutils ncurses # <- nano and /bin/ls link with

are we all on the same page now ? :)
Comment 17 Ryan Hill (RETIRED) gentoo-dev 2005-03-25 00:22:01 UTC
ah, okay.  your last comment seemed to indicate the flag would determine which of the libraries would be installed, rather than which to link to.  sorry bout the misunderstanding.
Comment 18 SpanKY gentoo-dev 2005-03-25 05:36:47 UTC
that is true too

USE=unicode will install the narrow ( and the wide ( while USE=-unicode will install just the narrow (