Why so many ports have run-dependencies on non-system gcc versions?

[Charlie Kester]

On Thu 21 May 2009 at 17:26:06 PDT Chris Cowart wrote:
>
>gcc provides a shared library that some applications link to. Take for
>example:
>
>ccowart dev-aux bin $ ldd sabcmd 
>sabcmd:
>        libsablot.so.70 => /usr/local/lib/libsablot.so.70 (0x2807f000)
>        libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x28148000)
>        libexpat.so.6 => /usr/local/lib/libexpat.so.6 (0x2823d000)
>        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x2825d000)
>        libm.so.5 => /lib/libm.so.5 (0x28352000)
>        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x28367000)
>        libc.so.7 => /lib/libc.so.7 (0x28372000)
>
>I can see this as being a real reason why a particular gcc needs to be
>around at runtime. Look at the dynamic linking information with ldd. If
>it doesn't depend on a file provided by those versions of gcc, it's
>probably an inaccuracy in the port's dependency list.

Here's the online documentation for libgcc, which describes what this
library provides: http://gcc.gnu.org/onlinedocs/gccint/Libgcc.html

Perhaps this lib should be made available as a seperate port that others
could list as a dependency, rather than the full-blown compiler suite?