From owner-freebsd-current@FreeBSD.ORG Sat Mar 12 01:37:01 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B320B106566C; Sat, 12 Mar 2011 01:37:01 +0000 (UTC) (envelope-from bf1783@googlemail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 489EA8FC0A; Sat, 12 Mar 2011 01:37:00 +0000 (UTC) Received: by yxl31 with SMTP id 31so1581062yxl.13 for ; Fri, 11 Mar 2011 17:37:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:reply-to:date:message-id:subject :from:to:content-type; bh=JYQZ7PD1YY8ewP7v85ev7FXvUn6p2vJi129fOtFj6QM=; b=AaLJ0Egr69Iu7PK8AVwUwpjIDaOaYgd0pay9EjGG3OSd/0UtA8YxjyWm/UzcUe5Hop 9Vs365/Vv3upOk+W0GbAexpd0IcedTdNl1ecVfoR1sDsJyqCG1h/G5a7j0Qe4UIUplzP vaDtJO55uAKGlruIw7vWCYf2p8miUns3toOnA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; b=Hv7tfIQ0ftubuOKo9sC5JvnzXc9flTEOB+m7i2TGc+4zK7KFGxOntWOV4704wT1RLW WH8xfWk8lLEPmDG3CrNCQjCGZtcpiMiR/qdwtfxRxH55wfRU6Ue5CPPS/YgyiXGZNWzS i0QT3J8APyWdySaBg/9XJvFRtJG4nqVdicKY4= MIME-Version: 1.0 Received: by 10.236.193.67 with SMTP id j43mr3677485yhn.241.1299893820465; Fri, 11 Mar 2011 17:37:00 -0800 (PST) Received: by 10.236.103.137 with HTTP; Fri, 11 Mar 2011 17:37:00 -0800 (PST) Date: Sat, 12 Mar 2011 01:37:00 +0000 Message-ID: From: "b. f." To: Kostik Belousov , Martin Matuska , Gerald Pfeifer , FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Re: FreeBSD Compiler Benchmark: gcc-base vs. gcc-ports vs. clang X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bf1783@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Mar 2011 01:37:01 -0000 > 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 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.