Summary: | =app-portage/gentoolkit-0.3.0.6 revdep-rebuild not detected libicui18n.so.48 needed by qt-core | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | David Kredba <kredba> |
Component: | [OLD] Library | Assignee: | Qt Bug Alias <qt> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | arfrever.fta, esigra, floppym, fuzzyray, gbugs, gentoo3, iprmaster, kripton, mkyral, nikoli, orionbelt2, phantom4, polynomial-c, qt, rich0, rose, yamadharma |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: |
https://bugzilla.redhat.com/show_bug.cgi?id=759923 https://bugs.gentoo.org/show_bug.cgi?id=449250 |
||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 394201 |
Description
David Kredba
2012-04-25 15:45:16 UTC
ldd /usr/bin/kmimetypefinder linux-vdso.so.1 (0x00007fff279ff000) libkdecore.so.5 => /usr/lib64/libkdecore.so.5 (0x00007f138cbee000) libQtCore.so.4 => /usr/lib64/qt4/libQtCore.so.4 (0x00007f138c716000) libc.so.6 => /lib64/libc.so.6 (0x00007f138c36f000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f138c152000) libQtNetwork.so.4 => /usr/lib64/qt4/libQtNetwork.so.4 (0x00007f138be03000) libQtDBus.so.4 => /usr/lib64/qt4/libQtDBus.so.4 (0x00007f138bb85000) libz.so.1 => /lib64/libz.so.1 (0x00007f138b96f000) libbz2.so.1 => /lib64/libbz2.so.1 (0x00007f138b75f000) liblzma.so.5 => /usr/lib64/liblzma.so.5 (0x00007f138b53c000) libfam.so.0 => /usr/lib64/libfam.so.0 (0x00007f138b335000) libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/libstdc++.so.6 (0x00007f138b031000) libm.so.6 => /lib64/libm.so.6 (0x00007f138ad3e000) librt.so.1 => /lib64/librt.so.1 (0x00007f138ab35000) libglib-2.0.so.0 => /usr/lib64/libglib-2.0.so.0 (0x00007f138a813000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f138a60f000) libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/libgcc_s.so.1 (0x00007f138a3f9000) /lib64/ld-linux-x86-64.so.2 (0x00007f138d0db000) libQtXml.so.4 => /usr/lib64/qt4/libQtXml.so.4 (0x00007f138a1b4000) libdbus-1.so.3 => /usr/lib64/libdbus-1.so.3 (0x00007f1389f77000) libelf.so.1 => /usr/lib64/libelf.so.1 (0x00007f1389d62000) It is one of the libreries linked. I do not understand the situation at all. ./kmimetypefinder freshly built during rebuild of the package in /var/tmp/portage/kde-base/kmimetypefinder-4.8.2/work/kmimetypefinder-4.8.2_build/kmimetypefinder is broken too: ./kmimetypefinder Unable to load library icui18n "Cannot load library icui18n: (libicui18n.so.48: sdílený objektový soubor nelze otevřít: Adresář nebo soubor neexistuje)" No filename specified srv5 kmimetypefinder # ldd ./kmimetypefinder linux-vdso.so.1 (0x00007fffd17ff000) libkdecore.so.5 => /usr/lib64/libkdecore.so.5 (0x00007f75e39b4000) libQtCore.so.4 => /usr/lib64/qt4/libQtCore.so.4 (0x00007f75e34dc000) libc.so.6 => /lib64/libc.so.6 (0x00007f75e3135000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f75e2f18000) libQtNetwork.so.4 => /usr/lib64/qt4/libQtNetwork.so.4 (0x00007f75e2bc9000) libQtDBus.so.4 => /usr/lib64/qt4/libQtDBus.so.4 (0x00007f75e294b000) libz.so.1 => /lib64/libz.so.1 (0x00007f75e2735000) libbz2.so.1 => /lib64/libbz2.so.1 (0x00007f75e2525000) liblzma.so.5 => /usr/lib64/liblzma.so.5 (0x00007f75e2302000) libfam.so.0 => /usr/lib64/libfam.so.0 (0x00007f75e20fb000) libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/libstdc++.so.6 (0x00007f75e1df7000) libm.so.6 => /lib64/libm.so.6 (0x00007f75e1b04000) librt.so.1 => /lib64/librt.so.1 (0x00007f75e18fb000) libglib-2.0.so.0 => /usr/lib64/libglib-2.0.so.0 (0x00007f75e15d9000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f75e13d5000) libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/libgcc_s.so.1 (0x00007f75e11bf000) /lib64/ld-linux-x86-64.so.2 (0x00007f75e3ea1000) libQtXml.so.4 => /usr/lib64/qt4/libQtXml.so.4 (0x00007f75e0f7a000) libdbus-1.so.3 => /usr/lib64/libdbus-1.so.3 (0x00007f75e0d3d000) libelf.so.1 => /usr/lib64/libelf.so.1 (0x00007f75e0b28000) automoc4 Unable to load library icui18n "Cannot load library icui18n: (libicui18n.so.48: sdílený objektový soubor nelze otevřít: Adresář nebo soubor neexistuje)" Usage: automoc4 <outfile> <srcdir> <builddir> <moc executable> <cmake executable> [--touch] strace automoc4 execve("/usr/bin/automoc4", ["automoc4"], [/* 201 vars */]) = 0 brk(0) = 0x200e000 -cut- open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 4 fstat(4, {st_mode=S_IFREG|0644, st_size=456592, ...}) = 0 mmap(NULL, 456592, PROT_READ, MAP_PRIVATE, 4, 0) = 0x7f6108e1b000 close(4) = 0 open("/lib64/tls/x86_64/icui18n", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat("/lib64/tls/x86_64", 0x7fff2eb28550) = -1 ENOENT (No such file or directory) open("/lib64/tls/icui18n", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat("/lib64/tls", 0x7fff2eb28550) = -1 ENOENT (No such file or directory) open("/lib64/x86_64/icui18n", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat("/lib64/x86_64", 0x7fff2eb28550) = -1 ENOENT (No such file or directory) open("/lib64/icui18n", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat("/lib64", {st_mode=S_IFDIR|0755, st_size=12288, ...}) = 0 open("/usr/lib64/tls/x86_64/icui18n", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat("/usr/lib64/tls/x86_64", 0x7fff2eb28550) = -1 ENOENT (No such file or directory) open("/usr/lib64/tls/icui18n", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat("/usr/lib64/tls", 0x7fff2eb28550) = -1 ENOENT (No such file or directory) open("/usr/lib64/x86_64/icui18n", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat("/usr/lib64/x86_64", 0x7fff2eb28550) = -1 ENOENT (No such file or directory) open("/usr/lib64/icui18n", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat("/usr/lib64", {st_mode=S_IFDIR|0755, st_size=266240, ...}) = 0 munmap(0x7f6108e1b000, 456592) = 0 open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 4 fstat(4, {st_mode=S_IFREG|0644, st_size=456592, ...}) = 0 mmap(NULL, 456592, PROT_READ, MAP_PRIVATE, 4, 0) = 0x7f6108e1b000 close(4) = 0 open("/lib64/icui18n.so.48", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib64/icui18n.so.48", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) munmap(0x7f6108e1b000, 456592) = 0 open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 4 fstat(4, {st_mode=S_IFREG|0644, st_size=456592, ...}) = 0 mmap(NULL, 456592, PROT_READ, MAP_PRIVATE, 4, 0) = 0x7f6108e1b000 close(4) = 0 open("/lib64/libicui18n", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib64/libicui18n", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) munmap(0x7f6108e1b000, 456592) = 0 open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 4 fstat(4, {st_mode=S_IFREG|0644, st_size=456592, ...}) = 0 mmap(NULL, 456592, PROT_READ, MAP_PRIVATE, 4, 0) = 0x7f6108e1b000 close(4) = 0 open("/lib64/libicui18n.so.48", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib64/libicui18n.so.48", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) munmap(0x7f6108e1b000, 456592) = 0 open("/usr/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 4 fcntl(4, F_GETFD) = 0x1 (flags FD_CLOEXEC) fstat(4, {st_mode=S_IFREG|0644, st_size=2570, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f6108efb000 read(4, "# Locale name alias data base.\n#"..., 4096) = 2570 read(4, "", 4096) = 0 close(4) = 0 munmap(0x7f6108efb000, 4096) = 0 open("/usr/share/locale/cs_CZ.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/share/locale/cs_CZ.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/share/locale/cs_CZ/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/share/locale/cs.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/share/locale/cs.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/share/locale/cs/LC_MESSAGES/libc.mo", O_RDONLY) = 4 fstat(4, {st_mode=S_IFREG|0644, st_size=145353, ...}) = 0 mmap(NULL, 145353, PROT_READ, MAP_PRIVATE, 4, 0) = 0x7f6108ed8000 close(4) = 0 write(2, "Unable to load library icui18n \""..., 161Unable to load library icui18n "Cannot load library icui18n: (libicui18n.so.48: sdílený objektový soubor nelze otevřít: Adresář nebo soubor neexistuje)" ) = 161 stat("/proc/17473/exe", {st_mode=S_IFREG|0755, st_size=60344, ...}) = 0 lstat("/proc/17473/exe", {st_mode=S_IFLNK|0777, st_size=0, ...}) = 0 lstat("/proc", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0 lstat("/proc/17473", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0 lstat("/proc/17473/exe", {st_mode=S_IFLNK|0777, st_size=0, ...}) = 0 readlink("/proc/17473/exe", "/usr/bin/automoc4", 4095) = 17 lstat("/usr", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 lstat("/usr/bin", {st_mode=S_IFDIR|0755, st_size=237568, ...}) = 0 lstat("/usr/bin/automoc4", {st_mode=S_IFREG|0755, st_size=60344, ...}) = 0 stat("/usr/bin/qt.conf", 0x7fff2eb29520) = -1 ENOENT (No such file or directory) stat("/usr/lib64/qt4/plugins", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 lstat("/usr", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 lstat("/usr/lib64", {st_mode=S_IFDIR|0755, st_size=266240, ...}) = 0 lstat("/usr/lib64/qt4", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 lstat("/usr/lib64/qt4/plugins", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 lstat("/usr", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 lstat("/usr/bin", {st_mode=S_IFDIR|0755, st_size=237568, ...}) = 0 stat("/usr/bin", {st_mode=S_IFDIR|0755, st_size=237568, ...}) = 0 lstat("/usr", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 lstat("/usr/lib64", {st_mode=S_IFDIR|0755, st_size=266240, ...}) = 0 lstat("/usr/lib64/kde4", {st_mode=S_IFDIR|0755, st_size=69632, ...}) = 0 lstat("/usr/lib64/kde4/plugins", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 pipe2([4, 5], O_NONBLOCK|O_CLOEXEC) = 0 rt_sigaction(SIGCHLD, {0x7f61089652e0, [], SA_RESTORER|SA_NOCLDSTOP, 0x7f6107f81c00}, {SIG_DFL, [], 0}, 8) = 0 lseek(2, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek) fstat(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 1), ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f6108ed7000 lseek(1, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek) fstat(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 1), ...}) = 0 brk(0x2051000) = 0x2051000 write(1, "Usage: automoc4 <outfile> <srcdi"..., 92Usage: automoc4 <outfile> <srcdir> <builddir> <moc executable> <cmake executable> [--touch] ) = 92 brk(0x2049000) = 0x2049000 write(5, "@", 1) = 1 close(5) = 0 close(4) = 0 rt_sigaction(SIGCHLD, NULL, {0x7f61089652e0, [], SA_RESTORER|SA_NOCLDSTOP, 0x7f6107f81c00}, 8) = 0 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x7f6107f81c00}, NULL, 8) = 0 exit_group(1) Something locale retrieval related? Would that be /usr/kde/4.0/bin/kmimetypefinder? It is /usr/bin/kmimetypefinder. But more KDE binaries are complaining about, like automoc4 in /usr/bin. I can confirm this bug. revdep-rebuild didn't find anything, but several kde-apps complain about missing library libicui18n.so.48. /usr/bin/konsole, /usr/bin/kwriteconfig and many others are complaining. As you can see, other people have this issue too (https://bugs.gentoo.org/show_bug.cgi?id=410777#c18). I also ran into a problem with revdep-rebuild not detecting all needed rebuilds after the icu update. In my case, it turned out to be either qt-core or qt-webkit that needed rebuilding. Ha! It was the qt-core! Thank you very much. How you found it please? *** Bug 413587 has been marked as a duplicate of this bug. *** I've reproduced this on my development system and libicu18n.so.48 is not in the ldd output or the needed sections when using scanelf in any of the linked libraries. Because of this, I don't see how this breakage can be detected by revdep-rebuild or the preserved-libs feature in portage 2.2. It appears to me that something in libQtCore.so.4 is trying to dynamically load the library and failing. (In reply to comment #11) > It appears to me that something in libQtCore.so.4 is trying to dynamically > load the library and failing. Yes, it appears that x11-libs/qt-core has an automagic dependency on dev-libs/icu. See the CFG_ICU variable in the qt-core configure script. This is used in src/corelib/tools/tools.pri to conditionally compile qlocale_icu.cpp, which tries to load libicui18n at runtime. (In reply to comment #12) > (In reply to comment #11) > > It appears to me that something in libQtCore.so.4 is trying to dynamically > > load the library and failing. > > Yes, it appears that x11-libs/qt-core has an automagic dependency on > dev-libs/icu. See the CFG_ICU variable in the qt-core configure script. > > This is used in src/corelib/tools/tools.pri to conditionally compile > qlocale_icu.cpp, which tries to load libicui18n at runtime. I am aware of that. The problem is that qt-core tries to load the particular versions of icui18n and icuuc that were available at build-time (but this might be an issue with the way we build icu itself). Anyway, even if icu libraries are uninstalled, everything (i.e. applications) should still work fine. *** Bug 413973 has been marked as a duplicate of this bug. *** (In reply to comment #13) > Anyway, even if icu libraries are uninstalled, everything (i.e. > applications) should still work fine. No, libreoffice-3.5.5.2 (localc) didn't started and KDE 4.8.3 login doesn't worked (but revdep-rebuild worked out those issues, see bug #415387) What about to change description of this bug? Revdep-rebuild works fine, qt-core is the problem source here. *** Bug 415387 has been marked as a duplicate of this bug. *** Function renaming in icu will be disabled at the next ABI break (i.e. icu-50), thus there's nothing we can do for now, except adding an ewarn to icu-49.x ebuilds suggesting to rebuild x11-libs/qt-core. Assigning to icu maintainer. *** Bug 414941 has been marked as a duplicate of this bug. *** *** Bug 416459 has been marked as a duplicate of this bug. *** Should Qt's icu detection really be automagic? That doesn't sound good. (In reply to comment #18) > Function renaming in icu will be disabled at the next ABI break (i.e. > icu-50), thus there's nothing we can do for now, except adding an ewarn to > icu-49.x ebuilds suggesting to rebuild x11-libs/qt-core. Even if function renaming is disabled in ICU 50 ebuilds and ICU 51 ebuilds, then x11-libs/qt-core would still have to be rebuilt after upgrading from ICU 50 to ICU 51. (In reply to comment #22) > (In reply to comment #18) > > Function renaming in icu will be disabled at the next ABI break (i.e. > > icu-50), thus there's nothing we can do for now, except adding an ewarn to > > icu-49.x ebuilds suggesting to rebuild x11-libs/qt-core. > > Even if function renaming is disabled in ICU 50 ebuilds and ICU 51 ebuilds, > then x11-libs/qt-core would still have to be rebuilt after upgrading from > ICU 50 to ICU 51. No. I intend to patch qt-core to dlopen() whatever version of icu is available on the system at run-time. (In reply to comment #21) > Should Qt's icu detection really be automagic? That doesn't sound good. That's a separate and orthogonal matter. Even if we added USE=icu to qt-core, people with it enabled would still be affected by this issue because libicui18n and libicuuc are not in DT_NEEDED for libQtCore.so Just want to voice my thoughts: Having a use flag and conditional dependency would at least make the relationship between qt-core and icu visible to tools like equery depends, qdepend -Q, pquery --revdep, etc. It could also allow icu support to be explicitly disabled at build time. It would be nice if libQtCore would actually include some indication of what code is trying to load icui18n; it currently shows up as messages on the console from many random applications. Do you think Qt upstream would be open to such a change? (In reply to comment #25) > Just want to voice my thoughts: > > Having a use flag and conditional dependency would at least make the > relationship between qt-core and icu visible to tools like equery depends, > qdepend -Q, pquery --revdep, etc. It could also allow icu support to be > explicitly disabled at build time. > Yeah, I totally agree, USE=icu in qt-core is already scheduled to be implemented for Qt 4.8.2 (due next week), I didn't want to touch 4.8.1 since it's being stabilized. > It would be nice if libQtCore would actually include some indication of what > code is trying to load icui18n; it currently shows up as messages on the > console from many random applications. Do you think Qt upstream would be > open to such a change? I think so, they're quite open to contributions. You'd need to check if the same applies to qt5 and land the patch there before backporting it to the 4.8 branch. Wouldn't a news item make sense for this, or a bump on qt-core to force a rebuild? The blog post was very helpful, as I just ran into this 10 minutes before reading this and hadn't looked into it yet. However, not everybody reads planet, and it isn't really a substitute for news. Long-term I agree that there are better ways to handle this, but for the moment it probably would both alleviate user pain, and cut down on the dups. It seems there was a fundamental lack of communication on this issue. The qt team didn't know that icu-49 was going stable in bug 394201, that's why I didn't bother to introduce USE=icu in qt-core-4.8.1. Now that both qt-core-4.8.1 and icu-49 are stable, this issue affects the stable tree too, which is very very bad. I'm going to commit a qt-core revbump that depends on >=icu-49 (if USE=icu is enabled) to force a rebuild, and fast-track it to stable. Comments? Other ideas? *qt-core-4.8.1-r3 (20 May 2012) 20 May 2012; Davide Pesavento <pesa@gentoo.org> +qt-core-4.8.1-r3.ebuild: Revbump introducing icu USE flag and forcing >=icu-49 to workaround bug #413541. I just had the same problem from the proprietary nvidia driver while launching X (startkde). It could not load dri/dri2 and complained with the error message: Unable to load library icui18n "Cannot load library icui18n: (libicui18n.so.48: cannot open shared object file: No such file or directory)" I had to downgrad to dev-libs/icu-4.8.1.1-r1 to start X. Assigning to qt, since we applied a workaround on our side... |