more thoughts as to why this is a bad idea ... how do you deal with runtime library requirements which only the compiler knows about ? sys-devel/gcc provides many runtime libraries such as libgcc_s.so. but whether the package actually needs that at runtime may depend purely on the arch/abi, or what code *just happens* to be generated. embedded cpus tend to need it more often than desktop cpus because libgcc_s.so provides fun things like 64bit multiplication and division routines when the hardware lacks support. so if your target happens to do 64bit multiplication, you now have RDEPEND on sys-devel/gcc.
glibc itself will load up libgcc_s.so via dlopen when unwinding in threaded situations. but this only necessary when the package uses threads, and needs unwind support (iirc), and glibc is using NPTL. you could say "ah just have glibc itself always require gcc", but if we're not being explicit in our deps, i dont see any difference from the implicit system set (except in the "worse" direction). these dependencies cannot be expressed via ebuilds/eclasses. -mike
signature.asc
Description: This is a digitally signed message part.
