From owner-freebsd-toolchain@FreeBSD.ORG Thu Apr 26 11:53:57 2012 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 861151065670; Thu, 26 Apr 2012 11:53:57 +0000 (UTC) (envelope-from theraven@theravensnest.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) by mx1.freebsd.org (Postfix) with ESMTP id 5144B8FC21; Thu, 26 Apr 2012 11:53:57 +0000 (UTC) Received: from [192.168.0.2] (cpc1-cwma8-2-0-cust171.7-3.cable.virginmedia.com [82.20.152.172]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id q3QBrmFK071697 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Thu, 26 Apr 2012 11:53:49 GMT (envelope-from theraven@theravensnest.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: David Chisnall In-Reply-To: <5BCE2E77-2B45-43B7-AB1F-6E6C13B87B34@gid.co.uk> Date: Thu, 26 Apr 2012 12:53:45 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120426093548.GR2358@deviant.kiev.zoral.com.ua> <5BCE2E77-2B45-43B7-AB1F-6E6C13B87B34@gid.co.uk> To: Bob Bishop X-Mailer: Apple Mail (2.1257) Cc: toolchain@freebsd.org, current@freebsd.org Subject: Re: [RFC] Un-staticise the toolchain X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 11:53:57 -0000 On 26 Apr 2012, at 12:38, Bob Bishop wrote: > Hi, >=20 > On 26 Apr 2012, at 10:35, Konstantin Belousov wrote: >=20 >> I think it is time to stop building the toolchain static. I was told = that >> original reasoning for static linking was the fear of loosing the = ability >> to recompile if some problem appears with rtld and any required = dynamic >> library. Apparently, current dependencies are much more spread, e.g. = /bin/sh >> is dynamically linked [etc] >=20 > That seems like a bad mistake, because it would prevent even booting = single-user if rtld/libraries are broken. That's what /rescue is for. You will find statically linked tools there = that are just about to repair a broken system (a static nc would also be = nice...). I did some benchmarks a little while ago, and there was, I think, about = a 5% slowdown on buildworld with a dynamically linked clang vs a = statically linked one on x86-64. Ideally, I'd want the bootstrap = compiler to be statically linked but the installed one to be dynamic. =20= The advantage of dynamic linking is small now, but as we add more LLVM = and clang-based tools to the base system (e.g. LLVM-based firewall JIT, = clang-based indent replacement) we're going to see lots of simple tools = being 5-10MB if we enforce static linking. =20 We'll probably get a much bigger speed win from clangd (hopefully = appearing in time for LLVM 3.2) avoiding the need to spawn a new process = for every compiler invocation than we'll save from static linking. =20 As to compiling things when rtld is broken... clang in the base system = currently dynamically links to lib[std]c++, libgcc_s, libm and libc, it = only statically links to the clang and LLVM libraries. David=