Bugzilla Bug 61592

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