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

[John Marino]

On 2/8/2014 09:20, Lev Serebryakov wrote:
> Hello, John.
> You wrote 8 февраля 2014 г., 3:39:37:
> 
>>>>> 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?
> 
> JM> dynamically linked libraries.
> JM> libcstd++
> JM> libgfortran
> JM> libquadmath
> JM> libssp
> JM> libgcc_s
> JM> etc,etc
>  90% of USE_GCC-ports don't use libgrotran & libquadmath. Many of them
> doesn;t use libstdc++. virtualbox-ose-additions DOESN'T USAE ANY OF THESE
> LIBRARIES! And I think, it is not unique in this regard!
> 
>  And, of course, 99.9% of them doesn't use Java!

It doesn't matter, you get everything that is built by default.  And you
need everything by default because sometimes gcc is needed for c++,
sometimes it's needed for fortran, sometimes it's needed for Ada
(gcc-aux), often the package has object files produced by different
languages but needs the same compiler to build them all.

So the only way to reduce unnecessary libraries is turn them off by
default, but that breaks lots of ports so you wouldn't do it.


> JM> Ah, yes it is.  See above.
> JM> GCC is built with GAS.  It needs the GAS that it's configured with.
>   But all these ports, which uses only libgcc_s and/or libstdc++ don't.
> 
>   You try to explain why it is as it is now, from purely formal, technical
>  point of view. I know, thank you.
> 
>   What It try to say, that now, when we have binary packages (thank you,
>  everybody, who make it possible!) and we don't have gcc in base on
>  10/CURRENT (and old gcc on older systems), we BADLY NEED way not to pull
>  0.5G of dependencies with any package, which was build with gcc!

If you have the gcc dynamic libraries, you have the gcc that uses them.
 If you have the gcc that uses them, it has a runtime dependency on the
binutils that built it.  All gcc built on FreeBSD have a dependency on
modern binutils (Not DragonFly though as they have binutils 2.22 and now
2.24 in base).

Unless the packages are purely static the entire gcc setup gets pulled
in.  But you only pay the price once. After that, every package pulling
in gcc is satisfied after the first one is installed.


> 
>>> 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.
> 
> JM> My feeling is that this isn't correct.
>  There are "-static-libgcc" and "-static-libstdc++" flags for gcc... What
> does they mean? I understand, that it is not for EACH port, but, maybe, for
> most of them they are Ok?

1st, that requires pretty invasive modification of whatever build system
works for that port, on a per-port basis.  Nobody is going to do that
extra work.
secondly, often packages don't build statically, they need dynamic for
some reason, often symbol visibility.

Like I said above, if you don't fix *ALL* of them, there's no point to
working on any of them.  Any port with USE_GCC=yes will pull in
everything anyway, so you'd have to kill them all.

I think most people will agree there are bigger fish to fry.  USE_GCC is
used as a last resort, they will slowly be removed as the packages get
fixed to work on clang (or clang gets better).

John