USE_GCC politic -- why so many ports has it as runtime dependency?

[John Marino]

On 2/8/2014 00:34, Lev Serebryakov wrote:
> Hello, Dimitry.
> You wrote 8 февраля 2014 г., 3:24:34:
> 
>>> And it seems, that most of USE_GCC-equipped ports pull all this development
>>> toolkit for nothing!
> DA> Well, some ports can be more or less difficult to get building with
> DA> clang.  So depending on whether the maintainer(s) wish to choose the way
> DA> of least resistance, they will sometimes decide to set USE_GCC.
>   I'm not speaking about BUILD. I'm speaking about RUN. Why do I need compiler,
> assembler, linker & Ko to run pre-build software?

dynamically linked libraries.
libcstd++
libgfortran
libquadmath
libssp
libgcc_s
etc,etc

> 
> DA> Since a lot (maybe even most?) of modern software requires something way
> DA> newer than our old gcc in base, and 10.0 and later ship without gcc by
> DA> default, it is logical to use lang/gcc in such cases too.

>   Yep. It is not logical to have gcc + binutils + libraries as RUNTIME
> dependency. Especially -- one with java (!) support. Does ANYBODY need
> crippled gcc-based Java support at all?! And pull it for KERNEL MODULES?!
> 0.5G doesn't looks a lot by current standards, I understand :(

Ah, yes it is.  See above.
GCC is built with GAS.  It needs the GAS that it's configured with.

> in case of USE_GCC, as libgcc.so + libstdc++.so is a tiiiiiiny fraction of full
> binutils + gcc package, and on non-developers system there is no need to
> have 0.5G of toolchain only because some software were build by this
> tooclahin on our build cluster!
> 
>  And I have feeling, that right now many cases of USE_GCC=any could be
> replaced with USE_GCC=any:build and some "magic" to link with
> libgcc/libstdc++ statically. Without any modularization of packages and
> pkgng support.

My feeling is that this isn't correct.

John