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

[Lev Serebryakov]

Hello, John.
You wrote 8 февраля 2014 г., 12:32:23:

>> 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!

JM> It doesn't matter, you get everything that is built by default.  And you
JM> need everything by default because sometimes gcc is needed for c++,
JM> sometimes it's needed for fortran, sometimes it's needed for Ada
JM> (gcc-aux), often the package has object files produced by different
JM> languages but needs the same compiler to build them all.
 (sigh). I now how it is done now. Again, I try to say, that it should
be changed. For example, gcc port could be split into
gcc/g++/gfrotran/gcc-aux/gcj/runtime ports. 90% of software need gcc and/or
g++. I never used gfortran or gnu ADA and I never-ever hear about projects,
which need specifically gcj, especially when we have native OpenJDK7!

 Look at QT, for example. It is splitted to components.

JM> So the only way to reduce unnecessary libraries is turn them off by
JM> default, but that breaks lots of ports so you wouldn't do it.
 I speak about unnecessary binaries, headers and stuff like that here. Look,

gcc-4.6.4     -  567.0MiB
binutils-2.24 -   49.2MiB
mpfr-3.1.2    -    1.6MiB
mpc-1.2.0     -    0.4MiB
gmp-5.1.3     -    2.3MiB

 (all data by "pkg info" output)

 At same time:

 libstdc++.so.6 - 5.5MiB
 libgcc_s.so    - 0.4MiB
 libssp.so      - 0.0MiB.

I'm sure, that 90% of USE_GCC ports use only these three libraries. It is
less than 1% of full toolchain size. You think it is Ok?

 Several ports could use libgfortran.so.3 (4.7MiB), libobjc.so.3 (0.5MiB)
 and libquadmath.so.0 (0.7MiB).

 I suspect, we don't have binary package, which needs libgcj.so
libgcj-tools.so (179MiB combined!).

JM> If you have the gcc dynamic libraries, you have the gcc that uses them.
   It is not obvious. Yes, now I have, but these libraries (10MiB) will work
  perfectly well without all other files (600MiB).

JM>  If you have the gcc that uses them, it has a runtime dependency on the
JM> binutils that built it.  All gcc built on FreeBSD have a dependency on
JM> modern binutils (Not DragonFly though as they have binutils 2.22 and now
JM> 2.24 in base).
  See above. virtualbox-ose-additions doesn't need assembler or linker or even
 compiler (ANY compiler) to work. Or any library, for that matter. Many
 ports needs one or two libraries, but not all this madness.

JM> Unless the packages are purely static the entire gcc setup gets pulled
JM> in.
  It is how we do things now, but it is not only way to do it and not better
 way for sure.

JM> Like I said above, if you don't fix *ALL* of them, there's no point to
JM> working on any of them.  Any port with USE_GCC=yes will pull in
JM> everything anyway, so you'd have to kill them all.
 It is perfectionism. May be, if we cover 50% of ports, but 50% which is
used by 95% of non-developing users (and other 50% is rarely used) it is
success.

-- 
// Black Lion AKA Lev Serebryakov <lev at FreeBSD.org>