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

John Marino at
Sat Feb 8 09:38:01 UTC 2014

On 2/8/2014 10:24, Lev Serebryakov wrote:
> 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!

Your "solution" causes multiple issues for others, and for what benefit?
 The libraries are not packaged individually.  You would need to split
up every GCC package into at least two packages, and then change the
infrastructure to add the compiler as the build dependency and the
libraries as a run dependency.  I do not see the library dependencies
getting whittled down to 5 - 15 separate packages though.  That is way
too much of a maintenance headache.

But the fact that you don't use use specific libraries is irrelevant.
The needs of the entire tree is what is being considered, as well as the
amount of work the maintainers are willing to do.  GCC x 5 is a set of
monster packages that I don't see a bunch of people clamoring to take over.

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

No, it's all or nothing.  And you are asking people to do a tremendous
amount of work to address a personal philosophy.  While I can see value
in splitting out the gcc libraries into separate packages (especially
when subpackages come where one can package libraries separately for
free), I see zero value in reworking vendor makefiles.  I'd never agree
to it myself, nor would I want a non-maintainer making an invasive
change like that.


More information about the freebsd-ports mailing list