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