Summary: | ncurses and the unicode USE flag, disabling unicode kills system | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Ryan Hill (RETIRED) <rhill> |
Component: | [OLD] Core system | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | RESOLVED FIXED | ||
Severity: | critical | CC: | devil, pasky, utf8, volchok |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://forums.gentoo.org/viewtopic.php?t=274175 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | Patch for warning user when emerging ncurses without unicode USE flag |
Description
Ryan Hill (RETIRED)
2005-01-17 00:02:11 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. 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) |