yes, this should look familiar. reference bug #64773, bug #74130, and bug #75927. also reference http://forums.gentoo.org/viewtopic.php?t=274175. 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/libncursesw.so.5. the workaround is to symlink /lib/libncurses.so.5 to /lib/libncursesw.so.5 and run revdep-rebuild --soname=libncursesw.so.5. 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. http://bugs.gentoo.org/show_bug.cgi?id=64773#c2 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 libncursesw.so || die "gen_usr_ldscript failed" gen_usr_ldscript libcursesw.so || die "gen_usr_ldscript failed" for i in ${D}/usr/$(get_libdir)/*w.*; do local libncurses=${i/${D}/} dosym ${libncurses} ${libncurses/w./.} done for i in ${D}/$(get_libdir)/libncursesw.so*; do local libncurses=${i/${D}} dosym ${libncurses} ${libncurses/w./.} done else # bug #4411 gen_usr_ldscript libncurses.so || die "gen_usr_ldscript failed" gen_usr_ldscript libcurses.so || die "gen_usr_ldscript failed" fi which seems to support the feasibility of this option. thanks. Reproducible: Always Steps to Reproduce:
*** This bug has been marked as a duplicate of 75927 ***
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.
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 3.4.3.20050110 (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.
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.
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 libncurses.so.(*) This program using libncursesw.so.(*). 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 libncurses.so.(*) and using only libncurses.so.(*) on unicode and on not unicode system. I think last way it's bad becouse we MUST rewriting some ebuilds.
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 ...
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.
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
the ebuild should check if previous versions are installed with unicode, to do so i'd check the existance of /usr/lib/libncursesw.so
--- 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/libncursesw.so ]; 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
i modified the patch a bit and applied it, the function is the same
ok, that is not satisfactory
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
and what's the benefit of that, that does not fix this problem
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?
ncurses.so and ncursesw.so 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 libncursesw.so < play around for a while, decide they dont want unicode > export USE=-unicode emerge nano coreutils ncurses # <- nano and /bin/ls link with libncurses.so are we all on the same page now ? :)
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.
that is true too USE=unicode will install the narrow (libncurses.so) and the wide (libncursesw.so) while USE=-unicode will install just the narrow (libncurses.so)
