Date: Sat, 12 Mar 2011 01:37:00 +0000 From: "b. f." <bf1783@googlemail.com> To: Kostik Belousov <kostikbel@gmail.com>, Martin Matuska <mm@FreeBSD.org>, Gerald Pfeifer <gerald@freebsd.org>, FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: FreeBSD Compiler Benchmark: gcc-base vs. gcc-ports vs. clang Message-ID: <AANLkTimA=q7jqG=e0ZUUoqWiGHFJD6ZvA%2BFdPb_CZjNM@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTimA=q7jqG=e0ZUUoqWiGHFJD6ZvA%2BFdPb_CZjNM>