Ok, I've found stupid problem during recompilation of my system (emerge -e world, USE="... directfb..." ) It seems that DirectFB depend on libSDL. Not in ebuild, but if you have already merged libsdl, then DirectFB make libdirectfb_sdl.so, which depend on libsdl. But libSDL can depend on DirectFB via "directfb" USE flag. So, in the situation, when libSDL broken (I just unmerge ggi and remove it from my USE before recompiling system, libSDL originaly was linked against libggi), for example, when you try to remerge both of them, portage choose to merge DirectFB first, because it known for portage, that libSDL depend on DirectFB...but...if you have already libSDL in the system, DirectFB trying to make libdirectfb_sdl.so and fail, if libSDL broken. Some kind of non-trivial cycling dependency. It need to be resolved somehow, I guess. But I really don't have ideas how exactly. BTW, it seems, if you build system from scratch and want both of them, and want from each support for another, you just can't :) libSDL will use DirectFB, but DirectFB will not use libSDL. One more merging of DirectFB will change situation. Very easy to reproduce. Just temporary remove some library, against of which is linked libSDL.so and try to emerge DirectFB. Or both of them, for pure experiment, with setted USE="directfb". It will fail.
Theoreticaly, ebuild of DirectFB should check for "sdl" in USE flags. But when you have swithed both flags, "sdl" and "directfb", you are coming to really funny problem, when build you system from scratch.
added code to DirectFB to disable SDL if libSDL.so is broken i'll update libsdl in a bit
added code for sdl now too
