It would appear that the recent upgrade to "media-libs/libcaca-0.99_beta16" may have deleted the old (circa 2007) equivalent links (e.g. /usr/lib/libcucul*) to the libcaca replacements. This breaks building a number of packages which *still* have references to either "-lcucul" or /usr/lib/libcucul.la, .so, etc. These packages may (or may not) require "libcaca" USE flags when being emerged to spring the problem. On my system several of these packages could be emerged without the libcaca option. Packages particularly include libsdl (relied on by DirectFB), xine-lib and vlc. Mplayer and/or transcode may be included as well. Any package which relies on libcaca (libcaca USE) should be checked to make sure it will still build with the libcaca option and *without* the old /usr/lib/libcucul.* files/links being present. Packages which do not build should be patched to use the "modern" libraries (and the developer's should be poked to configure the packages to use the up-to-date libraries). There is a fair amount of discussion on various Ubuntu / Debian & other Linux bug databases | blogs about this problem and the need to resolve it. A temporary fix would appear to be to recreate the symbolic links but this isn't a good long term solution as it propagates library name misuse. Reproducible: Always Steps to Reproduce: 1. emerge libcaca (-0.99_beta16) 2. Run revdep-rebuild Actual Results: Notice revdep flagging many libraries and packages depending on "libcucul.*" needing rebuilding. Attempt to rebuild and rebuilds will fail because libcucul no longer exists. Expected Results: Various out-of-date packages should configure themselves to use the "modern" libcaca rather than the outdated libcucul libraries.
the order in which revdep-rebuild tries to rebuild the packages is wrong, i did it by hand a long time ago (many months) when i was hit by this problem. if i remember correctly most gnome stuff was to be rebuild starting with pango or cairo or so and the up the ladder till everything was rebuilt.
Revdep-rebuild may have problems with the build order -- if they do a topological sort, e.g. tsort, on the list the can have circular references and those can be problematic (though if one has circular references one would question how the packages get built in the first place...) -- but the Revdep-rebuild order isn't the problem in this case. The problem appears to be that at some point in the past the core developers either renamed or subsumed libcucul into libcaca. The older gentoo ebuilds for libcaca seem to have solved this problem by creating symbolic links from the libcucul files to the libcaca replacements. The most recent ebuild (Makefile?) for libcaca doesn't seem to do that anymore. In any case, the *real* fix is to the ebuilds (configures/Makefiles) for the packages which still insist on using libcucul. This could be accomplished by applying patches to the configure files for those packages or bumping it upstream to the core developers to make the configuration bi-functional depending on the system environment in which it is run.
I've got that exact same problem here: vlc and mjpegtools fail to build, since they cannot find /usr/lib/libcucul.la A temporary workaround would be nice, but I don't know how to recreate libcucul.la though :$
I got rid of most of my problems by removing the libcaca flags from media-libs/libsdl and media-video/vlc. A lot of packages appear to depend on libsdl so a lot of them have added various load flags to include libcucul (libcaca). But in case you need it, here is the a libcucul.la and libcucul++.la from Jan 23, 2007, though they seem to have been generated back in 2005 (its soooo... nice having large disks where one just creates a snapshot of the critical directories from time to time): #-----------------------------------------------------------------------------# # libcucul.la - a libtool library file # Generated by ltmain.sh - GNU libtool 1.5.22 (1.1220.2.365 2005/12/18 22:14:06) # # Please DO NOT delete this file! # It is necessary for linking the library. # The name that we can dlopen(3). dlname='libcucul.so.0' # Names of this library. library_names='libcucul.so.0.99.0 libcucul.so.0 libcucul.so' # The name of the static archive. old_library='libcucul.a' # Libraries that this one depends upon. dependency_libs='' # Version information for libcucul. current=99 age=99 revision=0 # Is this an already installed library? installed=yes # Should we warn about portability when linking against -modules? shouldnotlink=no # Files to dlopen/dlpreopen dlopen='' dlpreopen='' # Directory that this library needs to be installed in: libdir='/usr/lib' #-----------------------------------------------------------------------------# And libcucul++.la though I don't think I've found any package that requires it yet. #-----------------------------------------------------------------------------# # libcucul++.la - a libtool library file # Generated by ltmain.sh - GNU libtool 1.5.22 (1.1220.2.365 2005/12/18 22:14:06) # # Please DO NOT delete this file! # It is necessary for linking the library. # The name that we can dlopen(3). dlname='libcucul++.so.0' # Names of this library. library_names='libcucul++.so.0.99.0 libcucul++.so.0 libcucul++.so' # The name of the static archive. old_library='libcucul++.a' # Libraries that this one depends upon. dependency_libs=' /usr/lib/libcucul.la' # Version information for libcucul++. current=99 age=99 revision=0 # Is this an already installed library? installed=yes # Should we warn about portability when linking against -modules? shouldnotlink=no # Files to dlopen/dlpreopen dlopen='' dlpreopen='' # Directory that this library needs to be installed in: libdir='/usr/lib' #-----------------------------------------------------------------------------#
emerge lafilefixer and lafilefixer --justfixit as a temp. solution, it's been known for a while revdep-rebuild can't set sane ordering in deptree dropping back to bug-wranglers --> not a libcaca issue
*** This bug has been marked as a duplicate of bug 241198 ***
