From owner-freebsd-toolchain@FreeBSD.ORG Thu Apr 26 09:36:09 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 40A3D106566B; Thu, 26 Apr 2012 09:36:09 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 9B08D8FC08; Thu, 26 Apr 2012 09:36:08 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q3Q9ZohB060021; Thu, 26 Apr 2012 12:35:50 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q3Q9ZnvS052823; Thu, 26 Apr 2012 12:35:49 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q3Q9ZngZ052822; Thu, 26 Apr 2012 12:35:49 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 26 Apr 2012 12:35:48 +0300 From: Konstantin Belousov To: toolchain@freebsd.org Message-ID: <20120426093548.GR2358@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="I1idRxCkzV0Ng7xp" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: current@freebsd.org Subject: [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 09:36:09 -0000 --I1idRxCkzV0Ng7xp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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, and statically linked make does not solve anything. Patch below makes the dynamically linked toolchain a default, adding an WITHOUT_SHARED_TOOLCHAIN build-time option for real conservators. I did not looked in details why including bsd.own.mk makes NO_MAN non-functional. Please see the diffs for gnu/usr.bin/cc1*/Makefile. gnu/usr.bin/binutils/ar/Makefile | 3 +++ gnu/usr.bin/binutils/as/Makefile | 3 +++ gnu/usr.bin/binutils/ld/Makefile | 3 +++ gnu/usr.bin/binutils/ranlib/Makefile | 3 +++ gnu/usr.bin/cc/cc/Makefile | 2 ++ gnu/usr.bin/cc/cc1/Makefile | 5 ++++- gnu/usr.bin/cc/cc1plus/Makefile | 5 ++++- share/mk/bsd.own.mk | 3 ++- tools/build/options/WITH_STATIC_TOOLCHAIN | 6 ++++++ usr.bin/ar/Makefile | 4 ++++ usr.bin/make/Makefile | 4 ++++ 11 files changed, 38 insertions(+), 3 deletions(-) diff --git a/gnu/usr.bin/binutils/ar/Makefile b/gnu/usr.bin/binutils/ar/Mak= efile index 464445e..e26be85 100644 --- a/gnu/usr.bin/binutils/ar/Makefile +++ b/gnu/usr.bin/binutils/ar/Makefile @@ -1,6 +1,7 @@ # $FreeBSD$ =20 .include "../Makefile.inc0" +.include =20 .PATH: ${SRCDIR}/binutils ${SRCDIR}/binutils/doc =20 @@ -16,7 +17,9 @@ CFLAGS+=3D -D_GNU_SOURCE CFLAGS+=3D -I${.CURDIR}/${RELTOP}/libbinutils CFLAGS+=3D -I${SRCDIR}/binutils CFLAGS+=3D -I${SRCDIR}/bfd +.if ${MK_SHARED_TOOLCHAIN} !=3D "no" NO_SHARED?=3D yes +.endif DPADD=3D ${RELTOP}/libbinutils/libbinutils.a DPADD+=3D ${RELTOP}/libbfd/libbfd.a DPADD+=3D ${RELTOP}/libiberty/libiberty.a diff --git a/gnu/usr.bin/binutils/as/Makefile b/gnu/usr.bin/binutils/as/Mak= efile index bf8df81..a39918c 100644 --- a/gnu/usr.bin/binutils/as/Makefile +++ b/gnu/usr.bin/binutils/as/Makefile @@ -4,6 +4,7 @@ # BINDIR .include "${.CURDIR}/../../Makefile.inc" .include "${.CURDIR}/../Makefile.inc0" +.include =20 .PATH: ${SRCDIR}/gas ${SRCDIR}/gas/config =20 @@ -79,7 +80,9 @@ CFLAGS+=3D -D_GNU_SOURCE CFLAGS+=3D -I${SRCDIR}/gas -I${SRCDIR}/bfd -I${SRCDIR}/gas/config -I${SRCD= IR} CFLAGS+=3D -I${.CURDIR} -I${.CURDIR}/${TARGET_CPUARCH}-freebsd =20 +.if ${MK_SHARED_TOOLCHAIN} !=3D "no" NO_SHARED?=3D yes +.endif =20 DPADD=3D ${RELTOP}/libbfd/libbfd.a DPADD+=3D ${RELTOP}/libiberty/libiberty.a diff --git a/gnu/usr.bin/binutils/ld/Makefile b/gnu/usr.bin/binutils/ld/Mak= efile index d4420ed..50d88b5 100644 --- a/gnu/usr.bin/binutils/ld/Makefile +++ b/gnu/usr.bin/binutils/ld/Makefile @@ -1,6 +1,7 @@ # $FreeBSD$ =20 .include "../Makefile.inc0" +.include =20 .PATH: ${SRCDIR}/ld =20 @@ -34,7 +35,9 @@ CFLAGS+=3D -DBINDIR=3D\"${BINDIR}\" -DTARGET_SYSTEM_ROOT= =3D\"${TOOLS_PREFIX}\" CFLAGS+=3D -DTOOLBINDIR=3D\"${TOOLS_PREFIX}/${BINDIR}/libexec\" CFLAGS+=3D -D_GNU_SOURCE CFLAGS+=3D -I${SRCDIR}/ld -I${SRCDIR}/bfd +.if ${MK_SHARED_TOOLCHAIN} !=3D "no" NO_SHARED?=3D yes +.endif DPADD=3D ${RELTOP}/libbfd/libbfd.a DPADD+=3D ${RELTOP}/libiberty/libiberty.a LDADD=3D ${DPADD} diff --git a/gnu/usr.bin/binutils/ranlib/Makefile b/gnu/usr.bin/binutils/ra= nlib/Makefile index 8679375..6d4b13e 100644 --- a/gnu/usr.bin/binutils/ranlib/Makefile +++ b/gnu/usr.bin/binutils/ranlib/Makefile @@ -1,6 +1,7 @@ # $FreeBSD$ =20 .include "../Makefile.inc0" +.include =20 .PATH: ${SRCDIR}/binutils ${SRCDIR}/binutils/doc =20 @@ -16,7 +17,9 @@ CFLAGS+=3D -D_GNU_SOURCE CFLAGS+=3D -I${.CURDIR}/${RELTOP}/libbinutils CFLAGS+=3D -I${SRCDIR}/binutils CFLAGS+=3D -I${SRCDIR}/bfd +.if ${MK_SHARED_TOOLCHAIN} !=3D "no" NO_SHARED?=3D yes +.endif DPADD=3D ${RELTOP}/libbinutils/libbinutils.a DPADD+=3D ${RELTOP}/libbfd/libbfd.a DPADD+=3D ${RELTOP}/libiberty/libiberty.a diff --git a/gnu/usr.bin/cc/cc/Makefile b/gnu/usr.bin/cc/cc/Makefile index 78c83a5..6a65d69 100644 --- a/gnu/usr.bin/cc/cc/Makefile +++ b/gnu/usr.bin/cc/cc/Makefile @@ -9,7 +9,9 @@ PROG=3D gcc MAN=3D gcc.1 SRCS+=3D gccspec.c =20 +.if ${MK_SHARED_TOOLCHAIN} !=3D "no" NO_SHARED?=3Dyes +.endif =20 MLINKS=3D gcc.1 g++.1 .if ${MK_CLANG_IS_CC} =3D=3D "no" diff --git a/gnu/usr.bin/cc/cc1/Makefile b/gnu/usr.bin/cc/cc1/Makefile index c65acd2..bb8fe19 100644 --- a/gnu/usr.bin/cc/cc1/Makefile +++ b/gnu/usr.bin/cc/cc1/Makefile @@ -1,14 +1,17 @@ # $FreeBSD$ =20 .include "../Makefile.inc" +.include =20 .PATH: ${GCCDIR} =20 PROG=3D cc1 SRCS=3D main.c c-parser.c c-lang.c BINDIR=3D /usr/libexec -NO_MAN=3D +MAN=3D +.if ${MK_SHARED_TOOLCHAIN} !=3D "no" NO_SHARED?=3Dyes +.endif =20 OBJS+=3D ${PROG}-checksum.o DPADD=3D ${LIBBACKEND} ${LIBCPP} ${LIBDECNUMBER} ${LIBIBERTY} diff --git a/gnu/usr.bin/cc/cc1plus/Makefile b/gnu/usr.bin/cc/cc1plus/Makef= ile index 964d20f..0bcbe61 100644 --- a/gnu/usr.bin/cc/cc1plus/Makefile +++ b/gnu/usr.bin/cc/cc1plus/Makefile @@ -1,6 +1,7 @@ # $FreeBSD$ =20 .include "../Makefile.inc" +.include =20 .PATH: ${GCCDIR}/cp ${GCCDIR} =20 @@ -13,8 +14,10 @@ SRCS+=3D main.c cp-lang.c c-opts.c call.c class.c cvt.c = cxx-pretty-print.c \ cp-objcp-common.c cp-gimplify.c tree-mudflap.c =20 BINDIR=3D /usr/libexec -NO_MAN=3D +MAN=3D +.if ${MK_SHARED_TOOLCHAIN} !=3D "no" NO_SHARED?=3Dyes +.endif =20 CFLAGS+=3D -I${GCCDIR}/cp -I. =20 diff --git a/share/mk/bsd.own.mk b/share/mk/bsd.own.mk index 55d6ba2..b0acbfd 100644 --- a/share/mk/bsd.own.mk +++ b/share/mk/bsd.own.mk @@ -425,7 +425,8 @@ __DEFAULT_NO_OPTIONS =3D \ ICONV \ IDEA \ LIBCPLUSPLUS \ - OFED + OFED \ + SHARED_TOOLCHAIN =20 # # Default behaviour of some options depends on the architecture. Unfortun= ately diff --git a/tools/build/options/WITH_STATIC_TOOLCHAIN b/tools/build/option= s/WITH_STATIC_TOOLCHAIN new file mode 100644 index 0000000..fa96a9f --- /dev/null +++ b/tools/build/options/WITH_STATIC_TOOLCHAIN @@ -0,0 +1,6 @@ +.\" $FreeBSD$ +Set to build the toolchain binaries static. +The set includes +.Xr cc 1 , +.Xr make 1 +and neccessary utilites like assembler, linker and librarian. \ No newline at end of file diff --git a/usr.bin/ar/Makefile b/usr.bin/ar/Makefile index e373120..72d1244 100644 --- a/usr.bin/ar/Makefile +++ b/usr.bin/ar/Makefile @@ -1,5 +1,7 @@ # $FreeBSD$ =20 +.include + PROG=3D ar SRCS=3D ar.c acplex.l acpyacc.y read.c util.c write.c y.tab.h =20 @@ -8,7 +10,9 @@ LDADD=3D -larchive -lelf =20 CFLAGS+=3D-I. -I${.CURDIR} =20 +.if ${MK_SHARED_TOOLCHAIN} !=3D "no" NO_SHARED?=3D yes +.endif LINKS=3D ${BINDIR}/ar ${BINDIR}/ranlib MLINKS=3D ar.1 ranlib.1 =20 diff --git a/usr.bin/make/Makefile b/usr.bin/make/Makefile index 2dc7e58..40243ed 100644 --- a/usr.bin/make/Makefile +++ b/usr.bin/make/Makefile @@ -2,13 +2,17 @@ # $Id: Makefile,v 1.6 1994/06/30 05:33:39 cgd Exp $ # $FreeBSD$ =20 +.include + PROG=3D make CFLAGS+=3D-I${.CURDIR} SRCS=3D arch.c buf.c cond.c dir.c for.c hash.c hash_tables.c job.c \ lst.c main.c make.c parse.c proc.c shell.c str.c suff.c targ.c \ util.c var.c =20 +.if ${MK_SHARED_TOOLCHAIN} !=3D "no" NO_SHARED?=3D YES +.endif =20 # Version has the RYYYYMMDDX format, where R is from RELENG_ CFLAGS+=3D-DMAKE_VERSION=3D\"5201111300\" --I1idRxCkzV0Ng7xp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk+ZFvQACgkQC3+MBN1Mb4ioDwCg0FGDd5XQ+B2gBxn5oMqGES3L hWwAmQH5aBsob67rbB2j4fzmC7K9NUo/ =vXCV -----END PGP SIGNATURE----- --I1idRxCkzV0Ng7xp-- From owner-freebsd-toolchain@FreeBSD.ORG Thu Apr 26 11:41:42 2012 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 90C8B106566B; Thu, 26 Apr 2012 11:41:42 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from mx0.gid.co.uk (mx0.gid.co.uk [194.32.164.250]) by mx1.freebsd.org (Postfix) with ESMTP id 28B4F8FC0A; Thu, 26 Apr 2012 11:41:41 +0000 (UTC) Received: from [194.32.164.22] (80-46-130-69.static.dsl.as9105.com [80.46.130.69]) by mx0.gid.co.uk (8.14.2/8.14.2) with ESMTP id q3QBcGgv077485; Thu, 26 Apr 2012 12:38:16 +0100 (BST) (envelope-from rb@gid.co.uk) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Bob Bishop In-Reply-To: <20120426093548.GR2358@deviant.kiev.zoral.com.ua> Date: Thu, 26 Apr 2012 12:38:03 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5BCE2E77-2B45-43B7-AB1F-6E6C13B87B34@gid.co.uk> References: <20120426093548.GR2358@deviant.kiev.zoral.com.ua> To: Konstantin Belousov X-Pgp-Agent: GPGMail 1.3.3 X-Mailer: Apple Mail (2.1084) 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:41:42 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, On 26 Apr 2012, at 10:35, Konstantin Belousov wrote: > 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] That seems like a bad mistake, because it would prevent even booting = single-user if rtld/libraries are broken. - -- Bob Bishop rb@gid.co.uk -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (Darwin) iD8DBQFPmTOivMaT6aS3xb8RAi1NAJ4gyvwPgdqtZjAERJ0grBsZYo5xBQCgikdo P4LXwI1rAbA23+29XWVV8w4=3D =3Di8e3 -----END PGP SIGNATURE----- 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= From owner-freebsd-toolchain@FreeBSD.ORG Thu Apr 26 12:01:02 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 501151065675; Thu, 26 Apr 2012 12:01:02 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 246058FC1D; Thu, 26 Apr 2012 12:01:02 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 415AAB94A; Thu, 26 Apr 2012 08:01:01 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Thu, 26 Apr 2012 07:52:01 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p13; KDE/4.5.5; amd64; ; ) References: <20120426093548.GR2358@deviant.kiev.zoral.com.ua> <5BCE2E77-2B45-43B7-AB1F-6E6C13B87B34@gid.co.uk> In-Reply-To: <5BCE2E77-2B45-43B7-AB1F-6E6C13B87B34@gid.co.uk> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201204260752.01127.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 26 Apr 2012 08:01:01 -0400 (EDT) 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 12:01:02 -0000 On Thursday, April 26, 2012 7:38:03 am Bob Bishop wrote: > Hi, > > On 26 Apr 2012, at 10:35, Konstantin Belousov wrote: > > > 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] > > That seems like a bad mistake, because it would prevent even booting single- user if rtld/libraries are broken. You could use /rescue/sh as your single-user shell. Of course, that would perhaps let you still be able to recompile things if you had a static toolchain. :) -- John Baldwin From owner-freebsd-toolchain@FreeBSD.ORG Thu Apr 26 12:01:12 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 1170E1065886; Thu, 26 Apr 2012 12:01:12 +0000 (UTC) (envelope-from erik@cederstrand.dk) Received: from csmtp3.one.com (csmtp3.one.com [91.198.169.23]) by mx1.freebsd.org (Postfix) with ESMTP id C65EE8FC0A; Thu, 26 Apr 2012 12:01:11 +0000 (UTC) Received: from [192.168.1.15] (unknown [217.157.7.221]) by csmtp3.one.com (Postfix) with ESMTPA id B271724064DC; Thu, 26 Apr 2012 12:01:08 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Erik Cederstrand In-Reply-To: <20120426093548.GR2358@deviant.kiev.zoral.com.ua> Date: Thu, 26 Apr 2012 14:01:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120426093548.GR2358@deviant.kiev.zoral.com.ua> To: Konstantin Belousov 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 12:01:12 -0000 Den 26/04/2012 kl. 11.35 skrev Konstantin Belousov: > 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, and statically linked make does not solve = anything. What are the benefits, apart from using a bit less disk space overall? Apparently, toolchain bits aren't considered important enough to be = included in /rescue. Maybe they need to be, if the assumption currently = is that the compiler will (almost) always work. Erik= From owner-freebsd-toolchain@FreeBSD.ORG Thu Apr 26 12:24:28 2012 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B8B19106566C; Thu, 26 Apr 2012 12:24:28 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 196A98FC15; Thu, 26 Apr 2012 12:24:28 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:2107:f730:ac0:5473] (unknown [IPv6:2001:7b8:3a7:0:2107:f730:ac0:5473]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 47F6E5C59; Thu, 26 Apr 2012 14:24:27 +0200 (CEST) Message-ID: <4F993E7C.9070400@FreeBSD.org> Date: Thu, 26 Apr 2012 14:24:28 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120420 Thunderbird/12.0 MIME-Version: 1.0 To: David Chisnall References: <20120426093548.GR2358@deviant.kiev.zoral.com.ua> <5BCE2E77-2B45-43B7-AB1F-6E6C13B87B34@gid.co.uk> In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 12:24:28 -0000 On 2012-04-26 13:53, David Chisnall wrote: ... > 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. This is already the case, all bootstrap toolchain components are statically linked: $ file /usr/obj/usr/src/tmp/usr/bin/* /usr/obj/usr/src/tmp/usr/bin/CC: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), statically linked, for FreeBSD 9.0 (900505), not stripped /usr/obj/usr/src/tmp/usr/bin/addr2line: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), statically linked, for FreeBSD 9.0 (900505), not stripped /usr/obj/usr/src/tmp/usr/bin/as: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), statically linked, for FreeBSD 9.0 (900505), not stripped /usr/obj/usr/src/tmp/usr/bin/bugpoint: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), statically linked, for FreeBSD 9.0 (900505), not stripped /usr/obj/usr/src/tmp/usr/bin/c++: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), statically linked, for FreeBSD 9.0 (900505), not stripped /usr/obj/usr/src/tmp/usr/bin/c++filt: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), statically linked, for FreeBSD 9.0 (900505), not stripped /usr/obj/usr/src/tmp/usr/bin/cc: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), statically linked, for FreeBSD 9.0 (900505), not stripped /usr/obj/usr/src/tmp/usr/bin/clang: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), statically linked, for FreeBSD 9.0 (900505), not stripped /usr/obj/usr/src/tmp/usr/bin/clang++: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), statically linked, for FreeBSD 9.0 (900505), not stripped /usr/obj/usr/src/tmp/usr/bin/clang-cpp: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), statically linked, for FreeBSD 9.0 (900505), not stripped /usr/obj/usr/src/tmp/usr/bin/clang-tblgen: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), statically linked, for FreeBSD 9.0 (900505), not stripped /usr/obj/usr/src/tmp/usr/bin/cpp: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), statically linked, for FreeBSD 9.0 (900505), not stripped /usr/obj/usr/src/tmp/usr/bin/g++: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), statically linked, for FreeBSD 9.0 (900505), not stripped /usr/obj/usr/src/tmp/usr/bin/gcc: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), statically linked, for FreeBSD 9.0 (900505), not stripped /usr/obj/usr/src/tmp/usr/bin/gcov: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), statically linked, for FreeBSD 9.0 (900505), not stripped /usr/obj/usr/src/tmp/usr/bin/gcpp: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), statically linked, for FreeBSD 9.0 (900505), not stripped /usr/obj/usr/src/tmp/usr/bin/gnu-ar: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), statically linked, for FreeBSD 9.0 (900505), not stripped /usr/obj/usr/src/tmp/usr/bin/gnu-ranlib: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), statically linked, for FreeBSD 9.0 (900505), not stripped /usr/obj/usr/src/tmp/usr/bin/ld: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), statically linked, for FreeBSD 9.0 (900505), not stripped /usr/obj/usr/src/tmp/usr/bin/lint: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), statically linked, for FreeBSD 9.0 (900505), not stripped /usr/obj/usr/src/tmp/usr/bin/llc: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), statically linked, for FreeBSD 9.0 (900505), not stripped /usr/obj/usr/src/tmp/usr/bin/lli: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), statically linked, for FreeBSD 9.0 (900505), not stripped /usr/obj/usr/src/tmp/usr/bin/llvm-ar: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), statically linked, for FreeBSD 9.0 (900505), not stripped /usr/obj/usr/src/tmp/usr/bin/llvm-as: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), statically linked, for FreeBSD 9.0 (900505), not stripped /usr/obj/usr/src/tmp/usr/bin/llvm-bcanalyzer: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), statically linked, for FreeBSD 9.0 (900505), not stripped /usr/obj/usr/src/tmp/usr/bin/llvm-diff: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), statically linked, for FreeBSD 9.0 (900505), not stripped /usr/obj/usr/src/tmp/usr/bin/llvm-dis: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), statically linked, for FreeBSD 9.0 (900505), not stripped /usr/obj/usr/src/tmp/usr/bin/llvm-extract: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), statically linked, for FreeBSD 9.0 (900505), not stripped /usr/obj/usr/src/tmp/usr/bin/llvm-ld: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), statically linked, for FreeBSD 9.0 (900505), not stripped /usr/obj/usr/src/tmp/usr/bin/llvm-link: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), statically linked, for FreeBSD 9.0 (900505), not stripped /usr/obj/usr/src/tmp/usr/bin/llvm-mc: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), statically linked, for FreeBSD 9.0 (900505), not stripped /usr/obj/usr/src/tmp/usr/bin/llvm-nm: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), statically linked, for FreeBSD 9.0 (900505), not stripped /usr/obj/usr/src/tmp/usr/bin/llvm-objdump: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), statically linked, for FreeBSD 9.0 (900505), not stripped /usr/obj/usr/src/tmp/usr/bin/llvm-prof: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), statically linked, for FreeBSD 9.0 (900505), not stripped /usr/obj/usr/src/tmp/usr/bin/llvm-ranlib: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), statically linked, for FreeBSD 9.0 (900505), not stripped /usr/obj/usr/src/tmp/usr/bin/llvm-rtdyld: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), statically linked, for FreeBSD 9.0 (900505), not stripped /usr/obj/usr/src/tmp/usr/bin/llvm-stub: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), statically linked, for FreeBSD 9.0 (900505), not stripped /usr/obj/usr/src/tmp/usr/bin/macho-dump: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), statically linked, for FreeBSD 9.0 (900505), not stripped /usr/obj/usr/src/tmp/usr/bin/nm: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), statically linked, for FreeBSD 9.0 (900505), not stripped /usr/obj/usr/src/tmp/usr/bin/objcopy: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), statically linked, for FreeBSD 9.0 (900505), not stripped /usr/obj/usr/src/tmp/usr/bin/objdump: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), statically linked, for FreeBSD 9.0 (900505), not stripped /usr/obj/usr/src/tmp/usr/bin/opt: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), statically linked, for FreeBSD 9.0 (900505), not stripped /usr/obj/usr/src/tmp/usr/bin/readelf: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), statically linked, for FreeBSD 9.0 (900505), not stripped /usr/obj/usr/src/tmp/usr/bin/size: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), statically linked, for FreeBSD 9.0 (900505), not stripped /usr/obj/usr/src/tmp/usr/bin/strings: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), statically linked, for FreeBSD 9.0 (900505), not stripped /usr/obj/usr/src/tmp/usr/bin/strip: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), statically linked, for FreeBSD 9.0 (900505), not stripped /usr/obj/usr/src/tmp/usr/bin/tblgen: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), statically linked, for FreeBSD 9.0 (900505), not stripped From owner-freebsd-toolchain@FreeBSD.ORG Thu Apr 26 12:31:07 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 868E3106564A; Thu, 26 Apr 2012 12:31:07 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id CD87E8FC08; Thu, 26 Apr 2012 12:31:06 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so1223344bkc.13 for ; Thu, 26 Apr 2012 05:31:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=yrIwbgvyqcSGZAVjsNCqnQqJn3MoJqmn+1kMk5i59NQ=; b=tJ3cFs3HUOyrtsx9uR9Ngf6jX/o0cdvT4rAlmerYpSEUsdbtEBjN/Ok46beqjczq9S AbKXvjeKNyH3xd/MMvVWoOYjK5vnSCIJOdDkqyyxNpW5nUzulbWi8/rEd7IcDrCeQOYM 4m2gKRvj0k/CrVRhyRrcGHAg1++ECxNUxlSau7WXYWlIAd8XjlHRm1drzmcaOFTCd6cX 7S8iQGoUsK9EbpM5M4Pd9m+GAgX2I6rP97ENo8hGVgVCWlykTHKZxJgdXqmPo4EXicET vas80HUYlVddixgE5Sn6nBO1+sti6EIlXzLVLRjn6NVI220ePjPHgsrQFnFAwvmXnpyQ euCQ== MIME-Version: 1.0 Received: by 10.204.151.75 with SMTP id b11mr2145835bkw.1.1335443465558; Thu, 26 Apr 2012 05:31:05 -0700 (PDT) Sender: utisoft@gmail.com Received: by 10.204.202.142 with HTTP; Thu, 26 Apr 2012 05:31:05 -0700 (PDT) Received: by 10.204.202.142 with HTTP; Thu, 26 Apr 2012 05:31:05 -0700 (PDT) In-Reply-To: References: <20120426093548.GR2358@deviant.kiev.zoral.com.ua> Date: Thu, 26 Apr 2012 13:31:05 +0100 X-Google-Sender-Auth: rmSwl8uUtN9dJ_0Zup95IaryCt0 Message-ID: From: Chris Rees To: toolchain@freebsd.org, current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: 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 12:31:07 -0000 Oops, just replied privately before: On Apr 26, 2012 12:39 PM, "Chris Rees" wrote: > > On Apr 26, 2012 10:36 AM, "Konstantin Belousov" > wrote: > > > > 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, and statically linked make does not solve > anything. > > > > Patch below makes the dynamically linked toolchain a default, adding an > > WITHOUT_SHARED_TOOLCHAIN build-time option for real conservators. > > Nice idea, but sh etc al are built statically as /rescue/sh. Will we see > /rescue/ar etc? > > Chris > From owner-freebsd-toolchain@FreeBSD.ORG Thu Apr 26 12:53:47 2012 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A2E4A106564A; Thu, 26 Apr 2012 12:53:47 +0000 (UTC) (envelope-from db@db.net) Received: from diana.db.net (diana.db.net [66.113.102.10]) by mx1.freebsd.org (Postfix) with ESMTP id 849028FC14; Thu, 26 Apr 2012 12:53:47 +0000 (UTC) Received: from night.db.net (localhost [127.0.0.1]) by diana.db.net (Postfix) with ESMTP id 937552282A; Thu, 26 Apr 2012 06:53:44 -0600 (MDT) Received: by night.db.net (Postfix, from userid 1000) id 63A805C7D; Thu, 26 Apr 2012 07:53:38 -0500 (EST) Date: Thu, 26 Apr 2012 07:53:38 -0500 From: Diane Bruce To: John Baldwin Message-ID: <20120426125338.GA9079@night.db.net> References: <20120426093548.GR2358@deviant.kiev.zoral.com.ua> <5BCE2E77-2B45-43B7-AB1F-6E6C13B87B34@gid.co.uk> <201204260752.01127.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201204260752.01127.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: toolchain@freebsd.org, freebsd-current@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 12:53:47 -0000 On Thu, Apr 26, 2012 at 07:52:01AM -0400, John Baldwin wrote: > On Thursday, April 26, 2012 7:38:03 am Bob Bishop wrote: > > Hi, > > ... > > You could use /rescue/sh as your single-user shell. Of course, that would > perhaps let you still be able to recompile things if you had a static > toolchain. :) Put a toolchain on a CD or memstick and use that instead? ;-) *runs* - Diane -- - db@FreeBSD.org db@db.net http://www.db.net/~db Why leave money to our children if we don't leave them the Earth? From owner-freebsd-toolchain@FreeBSD.ORG Thu Apr 26 13:41:42 2012 Return-Path: Delivered-To: toolchain@freebsd.org Received: from lo0.su (repoman.freebsd.org [IPv6:2001:4f8:fff6::29]) by hub.freebsd.org (Postfix) with ESMTP id 0CA45106567C; Thu, 26 Apr 2012 13:41:40 +0000 (UTC) (envelope-from ru@FreeBSD.org) Date: Thu, 26 Apr 2012 17:41:40 +0400 From: Ruslan Ermilov To: Konstantin Belousov Message-ID: <20120426134140.GF14350@lo0.su> References: <20120426093548.GR2358@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120426093548.GR2358@deviant.kiev.zoral.com.ua> 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 13:41:42 -0000 On Thu, Apr 26, 2012 at 12:35:48PM +0300, Konstantin Belousov wrote: > 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, and statically linked make does not solve anything. ------------------------------------------------------------------------ r76801 | sobomax | 2001-05-18 13:05:56 +0400 (Fri, 18 May 2001) | 6 lines By default build make(1) as a static binary. It costs only 100k of additional disk space, buf provides measureable speed increase for make-intensive operations, such as pkg_version(1), `make world' and so on. MFC after: 1 week ------------------------------------------------------------------------ Have things changed enough that the above is not true anymore? > Patch below makes the dynamically linked toolchain a default, adding an > WITHOUT_SHARED_TOOLCHAIN build-time option for real conservators. > > I did not looked in details why including bsd.own.mk makes NO_MAN > non-functional. Please see the diffs for gnu/usr.bin/cc1*/Makefile. Because you include bsd.own.mk before NO_MAN is defined, and the way how .if works in make(1). From owner-freebsd-toolchain@FreeBSD.ORG Thu Apr 26 19:01:40 2012 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C6D2F106564A; Thu, 26 Apr 2012 19:01:40 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id EA8AA8FC12; Thu, 26 Apr 2012 19:01:39 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so1677929bkc.13 for ; Thu, 26 Apr 2012 12:01:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=nb7WDSu21G1M44+Aud+ZPqQwbQ1yZ6bqP6L+tXL10sE=; b=hXHnwL507UrVX/PFVlgnvAA0Y7P6WYHlsYmMO6a6SEnngdtWYl8X37imX9JlXf2ZYV jR/+VSaGbV7nyUks9DWUEq47zeinAiC1++O5YkmMSKCDRfLCoOMHjTVy9YUNnuP+RiXj JAKlTg/WFkEBGdBKMhrjRMjlp/eaO/+bnoDjbQskl6iQXKeyJya+Fc/631JFDWgvmjqU 4mmtjScA+gDwgWX/SfPv/y59Ozo47i6mouxoEcv2pcVR32BtHbS4E4/7JItqcwBZhHah 9prZ3ns2qBHJ8L0VSi5VJNJD6futQ66xQHgB1gwE/oV0fZ6+rReWsD+YraVIGnpSfaEi vxww== Received: by 10.205.132.16 with SMTP id hs16mr2717046bkc.115.1335466898705; Thu, 26 Apr 2012 12:01:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.202.142 with HTTP; Thu, 26 Apr 2012 12:01:08 -0700 (PDT) In-Reply-To: <20120426134140.GF14350@lo0.su> References: <20120426093548.GR2358@deviant.kiev.zoral.com.ua> <20120426134140.GF14350@lo0.su> From: Chris Rees Date: Thu, 26 Apr 2012 20:01:08 +0100 Message-ID: To: Ruslan Ermilov Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 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 19:01:40 -0000 On Apr 26, 2012 2:42 PM, "Ruslan Ermilov" wrote: > > On Thu, Apr 26, 2012 at 12:35:48PM +0300, Konstantin Belousov wrote: > > 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, and statically linked make does not solve anything. > > ------------------------------------------------------------------------ > r76801 | sobomax | 2001-05-18 13:05:56 +0400 (Fri, 18 May 2001) | 6 lines > > By default build make(1) as a static binary. It costs only 100k of additional > disk space, buf provides measureable speed increase for make-intensive > operations, such as pkg_version(1), `make world' and so on. > > MFC after: 1 week > > ------------------------------------------------------------------------ > > Have things changed enough that the above is not true anymore? Well, the most make(1)-intensive test I can think of is make index, so some results from a quick test: hydra# uname -a FreeBSD hydra.bayofrum.net 9.0-RELEASE FreeBSD 9.0-RELEASE #7: Sun Apr 22 21:02:48 BST 2012 root@hydra.bayofrum.net:/usr/obj/usr/src/sys/HYDRA amd64 hydra# cd /usr/src/usr.bin/make && make NO_SHARED=yes && cp make ~/bin/make-static >& /dev/null hydra# rm make && make NO_SHARED=no && cp make ~/bin/make-dynamic >& /dev/null hydra# file ~/bin/make-* /home/chris/bin/make-dynamic: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), dynamically linked (uses shared libs), for FreeBSD 9.0 (900044), not stripped /home/chris/bin/make-static: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), statically linked, for FreeBSD 9.0 (900044), not stripped hydra# cd /usr/ports && time make MAKE=~crees/bin/make-static index Generating INDEX-9 - please wait.. Done. 729.770u 120.841s 7:45.10 182.8% 920+2676k 5251+116484io 7750pf+0w hydra# time make MAKE=~crees/bin/make-dynamic index Generating INDEX-9 - please wait.. Done. 771.320u 133.540s 8:07.83 185.4% 609+2918k 474+116484io 570pf+0w We have a 10% slowdown (or 11% speedup, depending on your figures) when using a dynamically loaded make. Chris From owner-freebsd-toolchain@FreeBSD.ORG Fri Apr 27 08:59:16 2012 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 25C3F106564A; Fri, 27 Apr 2012 08:59:16 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 9D1868FC1A; Fri, 27 Apr 2012 08:59:15 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q3R8wxt3069719; Fri, 27 Apr 2012 11:58:59 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q3R8wxEm033531; Fri, 27 Apr 2012 11:58:59 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q3R8wxkA033530; Fri, 27 Apr 2012 11:58:59 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 27 Apr 2012 11:58:59 +0300 From: Konstantin Belousov To: Ruslan Ermilov Message-ID: <20120427085859.GY2358@deviant.kiev.zoral.com.ua> References: <20120426093548.GR2358@deviant.kiev.zoral.com.ua> <20120426134140.GF14350@lo0.su> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DSqUood0rpsROwaK" Content-Disposition: inline In-Reply-To: <20120426134140.GF14350@lo0.su> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua 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: Fri, 27 Apr 2012 08:59:16 -0000 --DSqUood0rpsROwaK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 26, 2012 at 05:41:40PM +0400, Ruslan Ermilov wrote: > On Thu, Apr 26, 2012 at 12:35:48PM +0300, Konstantin Belousov wrote: > > I think it is time to stop building the toolchain static. I was told th= at > > original reasoning for static linking was the fear of loosing the abili= ty > > to recompile if some problem appears with rtld and any required dynamic > > library. Apparently, current dependencies are much more spread, e.g. /b= in/sh > > is dynamically linked, and statically linked make does not solve anythi= ng. >=20 > ------------------------------------------------------------------------ > r76801 | sobomax | 2001-05-18 13:05:56 +0400 (Fri, 18 May 2001) | 6 lines >=20 > By default build make(1) as a static binary. It costs only 100k of additi= onal > disk space, buf provides measureable speed increase for make-intensive > operations, such as pkg_version(1), `make world' and so on. >=20 > MFC after: 1 week >=20 > ------------------------------------------------------------------------ >=20 > Have things changed enough that the above is not true anymore? >=20 > > Patch below makes the dynamically linked toolchain a default, adding an > > WITHOUT_SHARED_TOOLCHAIN build-time option for real conservators. > >=20 > > I did not looked in details why including bsd.own.mk makes NO_MAN > > non-functional. Please see the diffs for gnu/usr.bin/cc1*/Makefile. >=20 > Because you include bsd.own.mk before NO_MAN is defined, and the way > how .if works in make(1). What is the 'right' thing to do then ? Postpone the inclusion of bsd.own.mk after NO_MAN definition ? This makes the .if $MK_SHARED_TOOLCHAIN to not work. Or, continue to do what I have done, using 'MAN=3D' instead ? N.B. I will commit the change, with defaults kept to build toolchain static, just to avoid bikeshed. --DSqUood0rpsROwaK Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk+aX9IACgkQC3+MBN1Mb4iq8wCghjt4unEw5lKeL7OvHxdh8QWf K3MAoIStz60XmlAapjxLB7skamxQjyxJ =Ygvx -----END PGP SIGNATURE----- --DSqUood0rpsROwaK-- From owner-freebsd-toolchain@FreeBSD.ORG Fri Apr 27 10:58:08 2012 Return-Path: Delivered-To: toolchain@freebsd.org Received: from lo0.su (repoman.freebsd.org [IPv6:2001:4f8:fff6::29]) by hub.freebsd.org (Postfix) with ESMTP id 321D2106564A; Fri, 27 Apr 2012 10:58:07 +0000 (UTC) (envelope-from ru@freebsd.org) Date: Fri, 27 Apr 2012 14:58:06 +0400 From: Ruslan Ermilov To: Konstantin Belousov Message-ID: <20120427105806.GB4477@lo0.su> References: <20120426093548.GR2358@deviant.kiev.zoral.com.ua> <20120426134140.GF14350@lo0.su> <20120427085859.GY2358@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120427085859.GY2358@deviant.kiev.zoral.com.ua> 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: Fri, 27 Apr 2012 10:58:08 -0000 On Fri, Apr 27, 2012 at 11:58:59AM +0300, Konstantin Belousov wrote: > On Thu, Apr 26, 2012 at 05:41:40PM +0400, Ruslan Ermilov wrote: > > On Thu, Apr 26, 2012 at 12:35:48PM +0300, Konstantin Belousov wrote: [...] > > > Patch below makes the dynamically linked toolchain a default, adding an > > > WITHOUT_SHARED_TOOLCHAIN build-time option for real conservators. > > > > > > I did not looked in details why including bsd.own.mk makes NO_MAN > > > non-functional. Please see the diffs for gnu/usr.bin/cc1*/Makefile. > > > > Because you include bsd.own.mk before NO_MAN is defined, and the way > > how .if works in make(1). > > What is the 'right' thing to do then ? > > Postpone the inclusion of bsd.own.mk after NO_MAN definition ? This makes > the .if $MK_SHARED_TOOLCHAIN to not work. > > Or, continue to do what I have done, using 'MAN=' instead ? Two ways, both are demonstrated by gnu/lib/libgcov/Makefile: - Define NO_* before including bsd.own.mk so it sets the corresponding MK_* variable appropriately, and before testing the MK_*. - Remove NO_*, include bsd.own.mk, then set MK_MAN=no. (The nearby gnu/lib/libssp/Makefile has a similar problem with NO_PROFILE.) > N.B. I will commit the change, with defaults kept to build toolchain static, > just to avoid bikeshed. I think this is the right approach. Regarding your patch... By placing SHARED_TOOLCHAIN to __DEFAULT_NO_OPTIONS list in bsd.own.mk, you already had MK_SHARED_TOOLCHAIN set to "no" by default, which preserves the current status quo of building toolchain static. But you misspelled tools/build/options/WITH_STATIC_TOOLCHAIN, probably as the result of iteratively modifying your change. The option and this file should be named WITH_SHARED_TOOLCHAIN, the opposite of the default. Anyway, checking that the resulting src.conf(5) manpage sounds sensible is a good idea. As for the contents of this file, I wouldn't call "ar/ranlib" a "librarian" but rather a "library archives manager", as per POSIX. Your diff also suggests that it misses a newline at EOF. From owner-freebsd-toolchain@FreeBSD.ORG Fri Apr 27 11:47:07 2012 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4772A106566B; Fri, 27 Apr 2012 11:47:07 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id A4ED08FC12; Fri, 27 Apr 2012 11:47:06 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q3RBl3Fa011630; Fri, 27 Apr 2012 14:47:03 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q3RBl21N034470; Fri, 27 Apr 2012 14:47:02 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q3RBl2kN034469; Fri, 27 Apr 2012 14:47:02 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 27 Apr 2012 14:47:02 +0300 From: Konstantin Belousov To: Ruslan Ermilov Message-ID: <20120427114702.GZ2358@deviant.kiev.zoral.com.ua> References: <20120426093548.GR2358@deviant.kiev.zoral.com.ua> <20120426134140.GF14350@lo0.su> <20120427085859.GY2358@deviant.kiev.zoral.com.ua> <20120427105806.GB4477@lo0.su> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LO1tiPwOBUf6PfOG" Content-Disposition: inline In-Reply-To: <20120427105806.GB4477@lo0.su> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua 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: Fri, 27 Apr 2012 11:47:07 -0000 --LO1tiPwOBUf6PfOG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 27, 2012 at 02:58:06PM +0400, Ruslan Ermilov wrote: > Regarding your patch... >=20 > By placing SHARED_TOOLCHAIN to __DEFAULT_NO_OPTIONS list in > bsd.own.mk, you already had MK_SHARED_TOOLCHAIN set to "no" by > default, which preserves the current status quo of building > toolchain static. But you misspelled > tools/build/options/WITH_STATIC_TOOLCHAIN, probably as the result > of iteratively modifying your change. The option and this file > should be named WITH_SHARED_TOOLCHAIN, the opposite of the > default. Anyway, checking that the resulting src.conf(5) manpage > sounds sensible is a good idea. As for the contents of this file, > I wouldn't call "ar/ranlib" a "librarian" but rather a "library > archives manager", as per POSIX. Your diff also suggests that it > misses a newline at EOF. Thank you for the suggestions. Below is the variant that should handle all the commentary. diff --git a/gnu/usr.bin/binutils/ar/Makefile b/gnu/usr.bin/binutils/ar/Mak= efile index 464445e..6fe22c8 100644 --- a/gnu/usr.bin/binutils/ar/Makefile +++ b/gnu/usr.bin/binutils/ar/Makefile @@ -1,6 +1,7 @@ # $FreeBSD$ =20 .include "../Makefile.inc0" +.include =20 .PATH: ${SRCDIR}/binutils ${SRCDIR}/binutils/doc =20 @@ -16,7 +17,9 @@ CFLAGS+=3D -D_GNU_SOURCE CFLAGS+=3D -I${.CURDIR}/${RELTOP}/libbinutils CFLAGS+=3D -I${SRCDIR}/binutils CFLAGS+=3D -I${SRCDIR}/bfd +.if ${MK_SHARED_TOOLCHAIN} =3D=3D "no" NO_SHARED?=3D yes +.endif DPADD=3D ${RELTOP}/libbinutils/libbinutils.a DPADD+=3D ${RELTOP}/libbfd/libbfd.a DPADD+=3D ${RELTOP}/libiberty/libiberty.a diff --git a/gnu/usr.bin/binutils/as/Makefile b/gnu/usr.bin/binutils/as/Mak= efile index bf8df81..5fef1f3 100644 --- a/gnu/usr.bin/binutils/as/Makefile +++ b/gnu/usr.bin/binutils/as/Makefile @@ -4,6 +4,7 @@ # BINDIR .include "${.CURDIR}/../../Makefile.inc" .include "${.CURDIR}/../Makefile.inc0" +.include =20 .PATH: ${SRCDIR}/gas ${SRCDIR}/gas/config =20 @@ -79,7 +80,9 @@ CFLAGS+=3D -D_GNU_SOURCE CFLAGS+=3D -I${SRCDIR}/gas -I${SRCDIR}/bfd -I${SRCDIR}/gas/config -I${SRCD= IR} CFLAGS+=3D -I${.CURDIR} -I${.CURDIR}/${TARGET_CPUARCH}-freebsd =20 +.if ${MK_SHARED_TOOLCHAIN} =3D=3D "no" NO_SHARED?=3D yes +.endif =20 DPADD=3D ${RELTOP}/libbfd/libbfd.a DPADD+=3D ${RELTOP}/libiberty/libiberty.a diff --git a/gnu/usr.bin/binutils/ld/Makefile b/gnu/usr.bin/binutils/ld/Mak= efile index d4420ed..ef19afa 100644 --- a/gnu/usr.bin/binutils/ld/Makefile +++ b/gnu/usr.bin/binutils/ld/Makefile @@ -1,6 +1,7 @@ # $FreeBSD$ =20 .include "../Makefile.inc0" +.include =20 .PATH: ${SRCDIR}/ld =20 @@ -34,7 +35,9 @@ CFLAGS+=3D -DBINDIR=3D\"${BINDIR}\" -DTARGET_SYSTEM_ROOT= =3D\"${TOOLS_PREFIX}\" CFLAGS+=3D -DTOOLBINDIR=3D\"${TOOLS_PREFIX}/${BINDIR}/libexec\" CFLAGS+=3D -D_GNU_SOURCE CFLAGS+=3D -I${SRCDIR}/ld -I${SRCDIR}/bfd +.if ${MK_SHARED_TOOLCHAIN} =3D=3D "no" NO_SHARED?=3D yes +.endif DPADD=3D ${RELTOP}/libbfd/libbfd.a DPADD+=3D ${RELTOP}/libiberty/libiberty.a LDADD=3D ${DPADD} diff --git a/gnu/usr.bin/binutils/ranlib/Makefile b/gnu/usr.bin/binutils/ra= nlib/Makefile index 8679375..052f9fe 100644 --- a/gnu/usr.bin/binutils/ranlib/Makefile +++ b/gnu/usr.bin/binutils/ranlib/Makefile @@ -1,6 +1,7 @@ # $FreeBSD$ =20 .include "../Makefile.inc0" +.include =20 .PATH: ${SRCDIR}/binutils ${SRCDIR}/binutils/doc =20 @@ -16,7 +17,9 @@ CFLAGS+=3D -D_GNU_SOURCE CFLAGS+=3D -I${.CURDIR}/${RELTOP}/libbinutils CFLAGS+=3D -I${SRCDIR}/binutils CFLAGS+=3D -I${SRCDIR}/bfd +.if ${MK_SHARED_TOOLCHAIN} =3D=3D "no" NO_SHARED?=3D yes +.endif DPADD=3D ${RELTOP}/libbinutils/libbinutils.a DPADD+=3D ${RELTOP}/libbfd/libbfd.a DPADD+=3D ${RELTOP}/libiberty/libiberty.a diff --git a/gnu/usr.bin/cc/cc/Makefile b/gnu/usr.bin/cc/cc/Makefile index 78c83a5..ba53565 100644 --- a/gnu/usr.bin/cc/cc/Makefile +++ b/gnu/usr.bin/cc/cc/Makefile @@ -9,7 +9,9 @@ PROG=3D gcc MAN=3D gcc.1 SRCS+=3D gccspec.c =20 +.if ${MK_SHARED_TOOLCHAIN} =3D=3D "no" NO_SHARED?=3Dyes +.endif =20 MLINKS=3D gcc.1 g++.1 .if ${MK_CLANG_IS_CC} =3D=3D "no" diff --git a/gnu/usr.bin/cc/cc1/Makefile b/gnu/usr.bin/cc/cc1/Makefile index c65acd2..7b1e343 100644 --- a/gnu/usr.bin/cc/cc1/Makefile +++ b/gnu/usr.bin/cc/cc1/Makefile @@ -1,14 +1,17 @@ # $FreeBSD$ =20 .include "../Makefile.inc" +NO_MAN=3D +.include =20 .PATH: ${GCCDIR} =20 PROG=3D cc1 SRCS=3D main.c c-parser.c c-lang.c BINDIR=3D /usr/libexec -NO_MAN=3D +.if ${MK_SHARED_TOOLCHAIN} =3D=3D "no" NO_SHARED?=3Dyes +.endif =20 OBJS+=3D ${PROG}-checksum.o DPADD=3D ${LIBBACKEND} ${LIBCPP} ${LIBDECNUMBER} ${LIBIBERTY} diff --git a/gnu/usr.bin/cc/cc1plus/Makefile b/gnu/usr.bin/cc/cc1plus/Makef= ile index 964d20f..dd3d524 100644 --- a/gnu/usr.bin/cc/cc1plus/Makefile +++ b/gnu/usr.bin/cc/cc1plus/Makefile @@ -1,6 +1,8 @@ # $FreeBSD$ =20 .include "../Makefile.inc" +NO_MAN=3D +.include =20 .PATH: ${GCCDIR}/cp ${GCCDIR} =20 @@ -13,8 +15,9 @@ SRCS+=3D main.c cp-lang.c c-opts.c call.c class.c cvt.c c= xx-pretty-print.c \ cp-objcp-common.c cp-gimplify.c tree-mudflap.c =20 BINDIR=3D /usr/libexec -NO_MAN=3D +.if ${MK_SHARED_TOOLCHAIN} =3D=3D "no" NO_SHARED?=3Dyes +.endif =20 CFLAGS+=3D -I${GCCDIR}/cp -I. =20 diff --git a/share/mk/bsd.own.mk b/share/mk/bsd.own.mk index 55d6ba2..b0acbfd 100644 --- a/share/mk/bsd.own.mk +++ b/share/mk/bsd.own.mk @@ -425,7 +425,8 @@ __DEFAULT_NO_OPTIONS =3D \ ICONV \ IDEA \ LIBCPLUSPLUS \ - OFED + OFED \ + SHARED_TOOLCHAIN =20 # # Default behaviour of some options depends on the architecture. Unfortun= ately diff --git a/tools/build/options/WITH_SHARED_TOOLCHAIN b/tools/build/option= s/WITH_SHARED_TOOLCHAIN new file mode 100644 index 0000000..48eea6d --- /dev/null +++ b/tools/build/options/WITH_SHARED_TOOLCHAIN @@ -0,0 +1,6 @@ +.\" $FreeBSD$ +Set to build the toolchain binaries shared. +The set includes +.Xr cc 1 , +.Xr make 1 +and neccessary utilites like assembler, linker and library archive manager. diff --git a/usr.bin/ar/Makefile b/usr.bin/ar/Makefile index e373120..e9bb893 100644 --- a/usr.bin/ar/Makefile +++ b/usr.bin/ar/Makefile @@ -1,5 +1,7 @@ # $FreeBSD$ =20 +.include + PROG=3D ar SRCS=3D ar.c acplex.l acpyacc.y read.c util.c write.c y.tab.h =20 @@ -8,7 +10,9 @@ LDADD=3D -larchive -lelf =20 CFLAGS+=3D-I. -I${.CURDIR} =20 +.if ${MK_SHARED_TOOLCHAIN} =3D=3D "no" NO_SHARED?=3D yes +.endif LINKS=3D ${BINDIR}/ar ${BINDIR}/ranlib MLINKS=3D ar.1 ranlib.1 =20 diff --git a/usr.bin/make/Makefile b/usr.bin/make/Makefile index 2dc7e58..f67cf50 100644 --- a/usr.bin/make/Makefile +++ b/usr.bin/make/Makefile @@ -2,13 +2,17 @@ # $Id: Makefile,v 1.6 1994/06/30 05:33:39 cgd Exp $ # $FreeBSD$ =20 +.include + PROG=3D make CFLAGS+=3D-I${.CURDIR} SRCS=3D arch.c buf.c cond.c dir.c for.c hash.c hash_tables.c job.c \ lst.c main.c make.c parse.c proc.c shell.c str.c suff.c targ.c \ util.c var.c =20 +.if ${MK_SHARED_TOOLCHAIN} =3D=3D "no" NO_SHARED?=3D YES +.endif =20 # Version has the RYYYYMMDDX format, where R is from RELENG_ CFLAGS+=3D-DMAKE_VERSION=3D\"5201111300\" --LO1tiPwOBUf6PfOG Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk+ahzYACgkQC3+MBN1Mb4ii+wCeMlwMjiu4g17+P7HZrfbaFPa3 /aMAoOWs/efEQOlrwE8Np89hI1hhDdNs =UpfA -----END PGP SIGNATURE----- --LO1tiPwOBUf6PfOG-- From owner-freebsd-toolchain@FreeBSD.ORG Fri Apr 27 22:34:03 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 8EC6810656D1 for ; Fri, 27 Apr 2012 22:34:03 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [70.36.220.4]) by mx1.freebsd.org (Postfix) with ESMTP id 4D71B8FC08 for ; Fri, 27 Apr 2012 22:34:03 +0000 (UTC) Received: from dhcp-192-168-2-14.wifi.xcllnt.net (atm.xcllnt.net [70.36.220.6]) (authenticated bits=0) by mail.xcllnt.net (8.14.5/8.14.5) with ESMTP id q3RMXnlq042629 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 27 Apr 2012 15:33:57 -0700 (PDT) (envelope-from marcel@xcllnt.net) From: Marcel Moolenaar Content-Type: multipart/mixed; boundary="Apple-Mail=_043ECEEC-E8F4-47C1-8A83-5577BA74EA34" Date: Fri, 27 Apr 2012 15:33:49 -0700 Message-Id: <7B7A25D1-E99D-486A-B1CA-A5CFEA837B81@xcllnt.net> To: Dmitry Mikulin Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Cc: toolchain@freebsd.org Subject: [GDB follow-fork] behavior change for wait() 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: Fri, 27 Apr 2012 22:34:03 -0000 --Apple-Mail=_043ECEEC-E8F4-47C1-8A83-5577BA74EA34 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Dmitry, I've been testing the follow-fork changes in GDB and ran into some weird behavior. Without gdb, my test program (attached) prints something like: fbsdvm% ./fe=20 fe(41042): initial process. Doing fork & exec... fe(41043): child after fork. Doing exec... fe(41043): child after exec. Exiting... fe(41042): child 41043 exited with status 0 In particular: the parent (pid=3D41042) calls wait(2) to reap the child = and the child exits with 0. Under gdb, I see this: fbsdvm% gdb ./fe GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you = are welcome to change it and/or distribute copies of it under certain = conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for = details. This GDB was configured as "i386-marcel-freebsd"... (gdb) br main Breakpoint 1 at 0x80487b0: file fe.c, line 14. (gdb) run Starting program: /usr/home/marcel/fe=20 Breakpoint 1, main (argc=3DError accessing memory address 0x1: Bad = address. ) at fe.c:14 14 { (gdb) n main (argc=3D1, argv=3D0xbfbfebb4) at fe.c:19 19 if (getenv("__FE_FORKED__") !=3D NULL) { (gdb) c Continuing. fe(41141): initial process. Doing fork & exec... [New process 41143] fe(41143): child after fork. Doing exec... fe(41143): child after exec. Exiting... fe(41141): wait(2) failed with error 10 (No child processes) Program exited normally. (gdb)=20 When stepping at least once, the inferior will not be able to properly = wait(2) for its child as it seems to have been reaped already. I suspect this is = done by the debugger -- unintentionally at least. Have you seen this before? --=20 Marcel Moolenaar marcel@xcllnt.net --Apple-Mail=_043ECEEC-E8F4-47C1-8A83-5577BA74EA34 Content-Disposition: attachment; filename=fe.c Content-Type: application/octet-stream; name="fe.c" Content-Transfer-Encoding: 7bit #include #include #include #include #include #include #include #include char *newenv[] = { "__FE_FORKED__=yes", NULL }; int main(int argc, char *argv[]) { int status; pid_t pid; /* Check if we exec'd ourselves after a fork. */ if (getenv("__FE_FORKED__") != NULL) { printf("%s(%d): child after exec. Exiting...\n", getprogname(), getpid()); return (0); } printf("%s(%d): initial process. Doing fork & exec...\n", getprogname(), getpid()); pid = fork(); switch (pid) { default: /* parent */ status = -1; pid = wait(&status); if (pid == -1) printf("%s(%d): wait(2) failed with error %d (%s)\n", getprogname(), getpid(), errno, strerror(errno)); else printf("%s(%d): child %d exited with status %d\n", getprogname(), getpid(), pid, status); break; case 0: /* child */ printf("%s(%d): child after fork. Doing exec...\n", getprogname(), getpid()); setenv("__FE_FORKED__", "done", 1); execve(getprogname(), argv, newenv); err(2, "exec failed"); break; case -1: err(1, "fork failed"); } return (0); } --Apple-Mail=_043ECEEC-E8F4-47C1-8A83-5577BA74EA34-- From owner-freebsd-toolchain@FreeBSD.ORG Sat Apr 28 03:12:13 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 D862A106566C; Sat, 28 Apr 2012 03:12:13 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id B32238FC0C; Sat, 28 Apr 2012 03:12:13 +0000 (UTC) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.5/8.14.5) with ESMTP id q3S3CDeu055110; Fri, 27 Apr 2012 20:12:13 -0700 (PDT) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.5/8.14.5/Submit) id q3S3CCkC055109; Fri, 27 Apr 2012 20:12:12 -0700 (PDT) (envelope-from obrien) Date: Fri, 27 Apr 2012 20:12:12 -0700 From: "David O'Brien" To: Bob Bishop Message-ID: <20120428031212.GE80419@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Bob Bishop , Konstantin Belousov , toolchain@freebsd.org, freebsd-current@freebsd.org References: <20120426093548.GR2358@deviant.kiev.zoral.com.ua> <5BCE2E77-2B45-43B7-AB1F-6E6C13B87B34@gid.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5BCE2E77-2B45-43B7-AB1F-6E6C13B87B34@gid.co.uk> X-Operating-System: FreeBSD 10.0-CURRENT X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? Precedence: bulk User-Agent: Mutt/1.5.20 (2009-06-14) Cc: toolchain@freebsd.org, freebsd-current@freebsd.org Subject: Re: [RFC] Un-staticise the toolchain X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Reply-To: obrien@freebsd.org List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Apr 2012 03:12:13 -0000 On Thu, Apr 26, 2012 at 12:38:03PM +0100, Bob Bishop wrote: > > Apparently, current dependencies are much more spread, e.g. /bin/sh > > is dynamically linked [etc] > > That seems like a bad mistake, because it would prevent even booting > single-user if rtld/libraries are broken. When one enters single user they are prompted for which shell to use. If /bin/sh is broken due to being dynamic, '/rescue/sh' will likely still work. -- -- David (obrien@FreeBSD.org) From owner-freebsd-toolchain@FreeBSD.ORG Sat Apr 28 03:12:50 2012 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A6B4F106566C; Sat, 28 Apr 2012 03:12:50 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id 7FDFE8FC0A; Sat, 28 Apr 2012 03:12:50 +0000 (UTC) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.5/8.14.5) with ESMTP id q3S3Co1v055124; Fri, 27 Apr 2012 20:12:50 -0700 (PDT) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.5/8.14.5/Submit) id q3S3CoCV055123; Fri, 27 Apr 2012 20:12:50 -0700 (PDT) (envelope-from obrien) Date: Fri, 27 Apr 2012 20:12:50 -0700 From: "David O'Brien" To: John Baldwin Message-ID: <20120428031250.GF80419@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, John Baldwin , freebsd-current@freebsd.org, Konstantin Belousov , toolchain@freebsd.org References: <20120426093548.GR2358@deviant.kiev.zoral.com.ua> <5BCE2E77-2B45-43B7-AB1F-6E6C13B87B34@gid.co.uk> <201204260752.01127.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201204260752.01127.jhb@freebsd.org> X-Operating-System: FreeBSD 10.0-CURRENT X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? Precedence: bulk User-Agent: Mutt/1.5.20 (2009-06-14) Cc: toolchain@freebsd.org, freebsd-current@freebsd.org Subject: Re: [RFC] Un-staticise the toolchain X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Reply-To: obrien@freebsd.org List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Apr 2012 03:12:50 -0000 On Thu, Apr 26, 2012 at 07:52:01AM -0400, John Baldwin wrote: > You could use /rescue/sh as your single-user shell. Of course, that would > perhaps let you still be able to recompile things if you had a static > toolchain. :) Having the toolchain static has saved me in exactly this way. -- -- David (obrien@FreeBSD.org) From owner-freebsd-toolchain@FreeBSD.ORG Sat Apr 28 10:03:29 2012 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B5CC7106564A; Sat, 28 Apr 2012 10:03:29 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from mx0.gid.co.uk (mx0.gid.co.uk [194.32.164.250]) by mx1.freebsd.org (Postfix) with ESMTP id 4EECB8FC17; Sat, 28 Apr 2012 10:03:29 +0000 (UTC) Received: from rbpbp.gid.co.uk (80-46-130-69.static.dsl.as9105.com [80.46.130.69]) by mx0.gid.co.uk (8.14.2/8.14.2) with ESMTP id q3SA3MA0052622; Sat, 28 Apr 2012 11:03:22 +0100 (BST) (envelope-from rb@gid.co.uk) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Bob Bishop In-Reply-To: <20120428031212.GE80419@dragon.NUXI.org> Date: Sat, 28 Apr 2012 11:03:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120426093548.GR2358@deviant.kiev.zoral.com.ua> <5BCE2E77-2B45-43B7-AB1F-6E6C13B87B34@gid.co.uk> <20120428031212.GE80419@dragon.NUXI.org> To: obrien@freebsd.org X-Mailer: Apple Mail (2.1084) Cc: toolchain@freebsd.org, freebsd-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: Sat, 28 Apr 2012 10:03:29 -0000 Hi, On 28 Apr 2012, at 04:12, David O'Brien wrote: > On Thu, Apr 26, 2012 at 12:38:03PM +0100, Bob Bishop wrote: >>> 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. >=20 > When one enters single user they are prompted for which shell to use. > If /bin/sh is broken due to being dynamic, '/rescue/sh' will likely = still > work. Yes. You to have a statically linked /rescue/sh on board, so what's the = point of /bin/sh being dynamic? The memory footprint really isn't an = issue, and for my money the default shell ought to be bombproof. -- Bob Bishop rb@gid.co.uk From owner-freebsd-toolchain@FreeBSD.ORG Sat Apr 28 16:59:29 2012 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7FAD21065672; Sat, 28 Apr 2012 16:59:29 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id F1A518FC18; Sat, 28 Apr 2012 16:59:28 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id q3SGxLHh093654; Sat, 28 Apr 2012 16:59:21 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id 5jkbja5wwf73r79eaizc9jey9i; Sat, 28 Apr 2012 16:59:21 +0000 (UTC) (envelope-from tim@kientzle.com) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: Date: Sat, 28 Apr 2012 09:59:20 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <225B99F7-00C7-4C1B-B2EF-8FE7F15A9F1F@kientzle.com> References: <20120426093548.GR2358@deviant.kiev.zoral.com.ua> <5BCE2E77-2B45-43B7-AB1F-6E6C13B87B34@gid.co.uk> <20120428031212.GE80419@dragon.NUXI.org> To: Bob Bishop X-Mailer: Apple Mail (2.1257) Cc: toolchain@freebsd.org, freebsd-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: Sat, 28 Apr 2012 16:59:29 -0000 On Apr 28, 2012, at 3:03 AM, Bob Bishop wrote: >=20 > On 28 Apr 2012, at 04:12, David O'Brien wrote: >=20 >> On Thu, Apr 26, 2012 at 12:38:03PM +0100, Bob Bishop wrote: >>>> 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. >>=20 >> When one enters single user they are prompted for which shell to use. >> If /bin/sh is broken due to being dynamic, '/rescue/sh' will likely = still >> work. >=20 > Yes. You to have a statically linked /rescue/sh on board, so what's = the point of /bin/sh being dynamic? The memory footprint really isn't an = issue, and for my money the default shell ought to be bombproof. By "default shell", I think you mean "the shell loaded by default in single user mode". That shell could be /rescue/sh. Single-user recovery does not require /bin/sh being static. Tim