[Differential] D22061: Build toolchain components as dynamically linked executables by default
dim created this revision. dim added reviewers: emaste, imp, jhb, kib. Herald added a subscriber: bdrewery. Herald added a reviewer: manpages. REVISION SUMMARY Historically, we have built toolchain components such as cc, ld, etc as statically linked executables. One of the reasons being that you could sometimes save yourself from botched upgrades, by e.g. recompiling a "known good" libc and reinstalling it. In this day and age, we have boot environments, virtual machine snapshots, cloud backups, and other much more reliable methods to restore systems to working order. So I think the time is ripe to flip this default, and link the toolchain components dynamically, just like almost all other executables on FreeBSD. Maybe at some point they can even become PIE executables by default! :) REPOSITORY rS FreeBSD src repository REVISION DETAIL https://reviews.freebsd.org/D22061 AFFECTED FILES share/man/man5/src.conf.5 share/mk/src.opts.mk tools/build/options/WITHOUT_SHARED_TOOLCHAIN EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: dim, emaste, imp, jhb, kib, #manpages Cc: bdrewery, freebsd-toolchain-list diff --git a/tools/build/options/WITHOUT_SHARED_TOOLCHAIN b/tools/build/options/WITHOUT_SHARED_TOOLCHAIN new file mode 100644 --- /dev/null +++ b/tools/build/options/WITHOUT_SHARED_TOOLCHAIN @@ -0,0 +1,6 @@ +.\" $FreeBSD$ +Set to build toolchain components as statically linked executables. +The set includes +.Xr cc 1 , +.Xr make 1 +and necessary utilities like assembler, linker and library archive manager. diff --git a/share/mk/src.opts.mk b/share/mk/src.opts.mk --- a/share/mk/src.opts.mk +++ b/share/mk/src.opts.mk @@ -166,6 +166,7 @@ SENDMAIL \ SERVICESDB \ SETUID_LOGIN \ +SHARED_TOOLCHAIN \ SHAREDOCS \ SOURCELESS \ SOURCELESS_HOST \ @@ -210,7 +211,6 @@ OPENLDAP \ REPRODUCIBLE_BUILD \ RPCBIND_WARMSTART_SUPPORT \ -SHARED_TOOLCHAIN \ SORT_THREADS \ SVN \ ZONEINFO_LEAPSECONDS_SUPPORT \ diff --git a/share/man/man5/src.conf.5 b/share/man/man5/src.conf.5 --- a/share/man/man5/src.conf.5 +++ b/share/man/man5/src.conf.5 @@ -1,6 +1,6 @@ .\" DO NOT EDIT-- this file is @generated by tools/build/options/makeman. .\" $FreeBSD$ -.Dd October 1, 2019 +.Dd October 16, 2019 .Dt SRC.CONF 5 .Os .Sh NAME @@ -197,7 +197,7 @@ of the normal system build. .Pp This is a default setting on -amd64/amd64, arm/arm, arm/armv6, arm/armv7, i386/i386, mips/mipsel, mips/mips, mips/mips64el, mips/mips64, mips/mipsn32, mips/mipselhf, mips/mipshf, mips/mips64elhf, mips/mips64hf, powerpc/powerpc, powerpc/powerpc64, powerpc/powerpcspe and sparc64/sparc64. +amd64/amd64, arm/arm, arm/armv6, arm/armv7, i386/i386, mips/mipsel, mips/mips, mips/mips64el, mips/mips64, mips/mipsn32, mips/mipselhf, mips/mipshf, mips/mips64elhf, mips/mips64hf and sparc64/sparc64. .It Va WITHOUT_BINUTILS_BOOTSTRAP Set to not build binutils (as, ld, and objdump) as part of the bootstrap process. @@ -213,7 +213,7 @@ as part of the bootstrap process. .Pp This is a default setting on -amd64/amd64, arm/arm, arm/armv6, arm/armv7, i386/i386, mips/mipsel, mips/mips, mips/mips64el, mips/mips64, mips/mipsn32, mips/mipselhf, mips/mipshf, mips/mips64elhf, mips/mips64hf, powerpc/powerpc, powerpc/powerpc64, powerpc/powerpcspe and sparc64/sparc64. +amd64/amd64, arm/arm, arm/armv6, arm/armv7, i386/i386, mips/mipsel, mips/mips, mips/mips64el, mips/mips64, mips/mipsn32, mips/mipselhf, mips/mipshf, mips/mips64elhf, mips/mips64hf and sparc64/sparc64. .It Va WITHOUT_BLACKLIST Set this if you do not want to build .Xr blacklistd 8 @@ -268,7 +268,7 @@ .Pa crtend.o . .Pp This is a default setting on -amd64/amd64, arm/arm, arm/armv6, arm/armv7, arm64/aarch64, i386/i386, mips/mipsel, mips/mips, mips/mips64el, mips/mips64, mips/mipsn32, mips/mipselhf, mips/mipshf, mips/mips64elhf, mips/mips64hf, powerpc/powerpc, powerpc/powerpc64, powerpc/powerpcspe and riscv/riscv64. +amd64/amd64, arm/arm, arm/armv6, arm/armv7, arm64/aarch64, i386/i386, riscv/riscv64, mips/mipsel, mips/mips, mips/mips64el, mips/mips64, mips/mipsn32, mips/mipselhf, mips/mipshf, mips/mips64elhf and mips/mips64hf. .It Va WITH_BSD_GREP Install BSD-licensed grep as '[ef]grep' instead of GNU grep. .It Va WITHOUT_BSNMP @@ -410,7 +410,7 @@ Set to build the Clang C/C++ compiler during the normal phase of the build. .Pp This is a default setting on -amd64/amd64, arm/arm, arm/armv6, arm/armv7, arm64/aarch64, i386/i386, mips/mipsel, mips/mips, mips/mips64el, mips/mips64, mips/mipsn32, mips/mipselhf, mips/mipshf, mips/mips64elhf, mips/mips64hf, powerpc/powerpc, powerpc/powerpc64 and powerpc/powerpcspe. +amd64/amd64, arm/arm, arm/armv6, arm/armv7, arm64/aarch64, i386/i386, mips/mipsel, mips/mips, mips/mips64el, mips/mips64, mips/mipsn32, mips/mipselhf, mips/mipshf, mips/mips64elhf and mips/mips64hf. .It Va WITHOUT_CLANG_BOOTSTRAP Set to not build the Clang C/C++ compiler during
[Bug 241257] ld.lld should be built as a static binary
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241257 --- Comment #8 from Dimitry Andric --- (In reply to Mike Cui from comment #5) > Because the base toolchain binaries are static I can almost always run newer > version on older systems. When I tried this going to 12.1 RC it didn't work > because ld.lld depended on a libc symbol I didn't have in 11. I understand that it can be a time-saver, but in general, even a statically linked binary from a newer release (and certainly a major release) is not guaranteed to run on an older kernel, specifically because there may have been changes in syscalls. That said, compilers and linkers tend to use a relatively minor set of those, and also the ones that don't change behavior very often (e.g. reading/writing files, basic process management). So these are less likely to break. :) -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 241257] ld.lld should be built as a static binary
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241257 Dimitry Andric changed: What|Removed |Added Status|New |In Progress -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 241257] ld.lld should be built as a static binary
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241257 --- Comment #7 from commit-h...@freebsd.org --- A commit references this bug: Author: dim Date: Wed Oct 16 17:11:18 UTC 2019 New revision: 353655 URL: https://svnweb.freebsd.org/changeset/base/353655 Log: Ensure lld respects the WITH/WITHOUT_SHARED_TOOLCHAIN option Traditionally, toolchain components such as cc, as, and ld have been built as static executables. The WITH_SHARED_TOOLCHAIN option from src.conf(5) is meant to link these as regular executables, e.g. using shared libraries. The build of ld.lld did not yet check this option. Fix the Makefile so it will do so now. Reported by: Mike Cui PR: 241257 MFC after:3 days Changes: head/usr.bin/clang/lld/Makefile -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 241257] ld.lld should be built as a static binary
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241257 --- Comment #6 from Ed Maste --- Agreed ld.lld should be consistent with the rest of the toolchain. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 241257] ld.lld should be built as a static binary
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241257
--- Comment #5 from Mike Cui ---
I agree that WITH_SHARED_TOOLCHAIN should be the default.
But here one small reason I care about having statically linked pre-built
toolchain binaries. I have a really slow Intel Atom machine, buildworld on this
machine takes 10+ hours, and most of that time is spent building llvm/clang
twice. To save the toolchain bootstrap time, nowadays I download base.txz from
the release I'm upgrading to, extract /usr/bin/{cc,c++,cpp,ld} and
/usr/lib/clang, then do a make buildworld WITHOUT_CROSS_COMPILER=1. It's a
massive timesaver. Because the base toolchain binaries are static I can almost
always run newer version on older systems. When I tried this going to 12.1 RC
it didn't work because ld.lld depended on a libc symbol I didn't have in 11.
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 241257] ld.lld should be built as a static binary
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241257 Alex Richardson changed: What|Removed |Added CC||arichard...@freebsd.org --- Comment #4 from Alex Richardson --- LLD doesn't need plugins for LTO since it should link against all necessary llvm code. That might obviously change if someone implements a plugin to LTO GCC-generated code. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 241257] ld.lld should be built as a static binary
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241257 --- Comment #3 from Konstantin Belousov --- I am not sure if base system lld supports LTO, but it definitely needs to be linked shared for this to work even theoretically. I suppose that the first obstacle is that we do not provide LTO linker plugin in base, but also in port. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 241257] ld.lld should be built as a static binary
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241257 --- Comment #2 from Konstantin Belousov --- (In reply to Dimitry Andric from comment #1) I am all for linking the toolchain shared, and I would even support removing WITH_SHARED_TOOLCHAIN at all, after it is flipped. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 241257] ld.lld should be built as a static binary
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241257 Dimitry Andric changed: What|Removed |Added CC||d...@freebsd.org, ||ema...@freebsd.org, ||k...@freebsd.org --- Comment #1 from Dimitry Andric --- I would rather get rid of the WITH_SHARED_TOOLCHAIN option, as it is rather nonsensical in this day and age. But indeed, it is now inconsistent. Ed, Kostik, do you think it is worth the trouble linking lld statically? Maybe we can flip the MK_SHARED_TOOLCHAIN default to "yes", while we are at it... -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
