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 <[email protected]> _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[email protected]"
