Re: FreeBSD Compiler Benchmark: gcc-base vs. gcc-ports vs. clang

> Putting the 'speed' question completely aside, I would like to comment
> on other issue(s) there. The switching of the ports to use the port-provided
> compiler (and binutils) would be very useful and often talked about feature.
>
> Your approach of USE_GCC_BUILD as implemented is probably not going
> to work. The problem is that gcc provides two libraries, libgcc and
> libstdc++, that are not forward-compatible with the same libraries from
> older compilers and our base.
>
> libstdc++ definitely did grown new symbols and new versions of old
> symbols, and I suspect that libgcc did the same. Also, we are trusting
> the ABI stability premise.
>
> For this scheme to work, we at least need a gcc-runtime port with dsos
> provided by full port, and some mechnanism to force the binaries
> compiled with port gcc to use gcc-runtime libs instead of base.
> Might be, -R<path> linker cludge.

There are a number of incompatible libraries.  The existing USE_GCC
scheme adds -Wl,rpath=... flags to CFLAGS and LDFLAGS in bsd.gcc.mk,
in an attempt to point the binaries to newer libraries.  Matuska is
not suggesting changing this -- his proposed new variable
USE_GCC_BUILD uses the existing USE_GCC framework, and differs from
the existing usage only in that it does not register any runtime
dependencies on lang/gcc*  in the packages that are produced.  His new
variable is intended, as he said, only for ports that don't need any
of the compiler libraries at runtime.

There are only two reasons for doing this: (1) reducing the number of
dependencies that must be installed when installing a package, or (2)
attempting to use lang/gcc4* to build a port that is currently needed
to build lang/gcc4* itself, without causing a problem with circular
dependencies.

For (2), I think that there are only:

devel/gmake
devel/binutils
devel/bison
lang/perl5.1[02]
devel/binutils
devel/libelf
converters/libiconv

(the others have runtime dependencies on libgcc_s) and the new
variable could not be added to the port Makefiles, because it would
still cause problems with circular dependencies when building these
ports if lang/gcc4* were not already installed.  It would have to be
added by users in local Makefiles, who had arranged their builds so
that it could be used.  But since the same effect could be obtained by
editing packages or the package database after the build, or by using
the methods Matuska advocated in:

http://www.freebsd.org/doc/en_US.ISO8859-1/articles/custom-gcc/index.html

the new variable does not seem to be worth including for the purpose of (2).

For (1), I'm not sure how many ports could use it.  We are already
working on reducing the amount of dependencies for those ports that
USE_FORTRAN or USE_GCC, by trying to add runtime-only lang/gcc4*
ports, but, owing to some awkward details involving the Ports
infrastructure and the way tinderboxes operate, the existing
lang/gcc4* ports have to be split into non-intersecting slave ports,
so there has been a delay while we sort out the details.

b.