Re: [RFC] Un-staticise the toolchain
On Thursday, May 03, 2012 5:18:15 am Erik Cederstrand wrote: > Den 02/05/2012 kl. 13.56 skrev John Baldwin: > >> > >> Static version: > >> * 0.09 ms spent execve'ing /usr/bin/make > >> * The rest is mostly sysctl calls > >> > >> Dynamic version: > >> * 0.09 ms spent execve'ing ./dynamicmake and /libexec/ld-elf.so.1 > >> * 0.18 ms spent loading libc.so.7 (incl. reading /etc/libmap.conf and /var/run/ld-elf.so.hints) > >> * 0.11 ms spent calling sysarch(0x81,0x7fff) (static version also does this but only uses 0.01 ms. No idea why) > >> * The rest is mostly sysctl and sigprocmask calls > > > > Keep in mind that the first time each system call is invoked, the runtime > > linker has to resolve the symbol. You can force the linker to do all > > that when the object is loaded instead by setting LD_BIND_NOW=yes in the > > environment of dynamicmake. If that makes the sysarch() call take 0.01 > > ms, then you know that the extra 0.10 ms is because of rtld doing the > > lookup of sysarch() on the first sysarch() call. > > Thanks for the suggestion. There is only a single sysarch() call in each version so I'm not sure that would help. Anyway, setting LD_BIND_NOW in the dynamic case just made the sysarch() call 0.20 ms slower without speeding up anything else. Hummm, that's odd that it was even slower. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] Un-staticise the toolchain
Den 02/05/2012 kl. 13.56 skrev John Baldwin: >> >> Static version: >> * 0.09 ms spent execve'ing /usr/bin/make >> * The rest is mostly sysctl calls >> >> Dynamic version: >> * 0.09 ms spent execve'ing ./dynamicmake and /libexec/ld-elf.so.1 >> * 0.18 ms spent loading libc.so.7 (incl. reading /etc/libmap.conf and >> /var/run/ld-elf.so.hints) >> * 0.11 ms spent calling sysarch(0x81,0x7fff) (static version also >> does this but only uses 0.01 ms. No idea why) >> * The rest is mostly sysctl and sigprocmask calls > > Keep in mind that the first time each system call is invoked, the runtime > linker has to resolve the symbol. You can force the linker to do all > that when the object is loaded instead by setting LD_BIND_NOW=yes in the > environment of dynamicmake. If that makes the sysarch() call take 0.01 > ms, then you know that the extra 0.10 ms is because of rtld doing the > lookup of sysarch() on the first sysarch() call. Thanks for the suggestion. There is only a single sysarch() call in each version so I'm not sure that would help. Anyway, setting LD_BIND_NOW in the dynamic case just made the sysarch() call 0.20 ms slower without speeding up anything else. Kind regards, Erik___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] Un-staticise the toolchain
On Tuesday, May 01, 2012 6:46:04 pm Erik Cederstrand wrote:
> Den 01/05/2012 kl. 15.55 skrev Gary Palmer:
> >
> > If you want a high-level view of what goes on run
> >
> > ldd `which ls`
> >
> > check that it has libraries to load and doesn't say "not a dynamic ELF
> > executable", and then run:
> >
> > ktrace ls
> > kdump | more
> >
> > All the system calls related to resolving and loading shared libraries
> > take time. I realise "ls" is not "make", but it should give you an
> > idea.
>
> Just for fun, I did some measurements with ktrace and a static vs dynamic
> make. I did 'ktrace make' and 'trace dynamicmake' ('dynamicmake'
produced by running 'make NO_SHARED=no' in /usr/src/usr.bin/make), just to see
where time is spent when loading and running make in the static and
dynamic cases. I did this 100 times for each version (discarding the first run)
and ran through ministat (numbers in msecs):
>
> x static.dat
> ++
> | x x
>|
> | x x x x x xx
>|
> | x x x x x xx x
>|
> |x x x x x x x x x x x x x
>|
> | x x x x x x x x x x x x x x x x x
>|
> | x x x x x x x x x x x x x x x x x x x x x x x
>|
> |x x x x x x x x x x x x x x x x x x x x x x x x x x x x x
> x|
> | |_M__A___|
>|
> ++
> N Min MaxMedian AvgStddev
> x 100 2.228 2.266 2.242 2.24333 0.00794
>
> x dynamic.dat
> ++
> |x
>|
> |xx
>|
> | xxx x x x
>|
> | xxx x x xx x
>|
> | x x xx x x xx x x x
>|
> | x xx x x xx x x xx x x x x
>|
> |x x x xx x x x xx x x x x xx x x x x xx
>|
> |x xx x x x xx x x x xx x x x x xx x x x x xx x x x x xx x x
> x x|
> | |_M_A___|
>|
> ++
> N Min MaxMedian AvgStddev
> x 100 2.648 2.691 2.6662.6669 0.00873
>
>
> So the dynamic version is ca. 0.42 ms, or 16%, slower on my system.
>
> I then compared a trace from a static and a dynamic 'make'. Both selected
> traces had a running time matching the median of that run. I cut away
all common system calls etc., which resulted in just the steps involved in
loading 'make' to a state where it can start executing.
>
> In the static case, this took 0.26 ms. In the dynamic case, this took 0.57
> ms, or 0.31 ms (119%) more. The remaining ca. 0.11 ms (0.42 - 0.31)
are mainly due to the dynamic version having slightly slower IO (read() and
stat()). I have no idea why. The following are the notable steps in
each version:
>
> Static version:
> * 0.09 ms spent execve'ing /usr/bin/make
> * The rest is mostly sysctl calls
>
> Dynamic version:
> * 0.09 ms spent execve'ing ./dynamicmake and /libexec/ld-elf.so.1
> * 0.18 ms spent loading libc.so.7 (incl. reading /etc/libmap.conf and
> /var/run/ld-elf.so.hints)
> * 0.11 ms spent calling sysarch(0x81,0x7fff) (static version also
> does this but only uses 0.01 ms. No idea why)
> * The rest is mostly sysctl and sigprocmask calls
Keep in mind that the first time each system call is invoked, the runtime
linker has to resolve the symbol. You can force the linker to do all
that when the object is loaded instead by setting LD_BIND_NOW=yes in the
environment of dynamicmake. If that makes the sysarch() call take 0.01
ms, then you know that the extra 0.10 ms is because of rtld doing the
lookup of sysarch() on the first sysarch() call.
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] Un-staticise the toolchain
Den 01/05/2012 kl. 15.55 skrev Gary Palmer:
>
> If you want a high-level view of what goes on run
>
> ldd `which ls`
>
> check that it has libraries to load and doesn't say "not a dynamic ELF
> executable", and then run:
>
> ktrace ls
> kdump | more
>
> All the system calls related to resolving and loading shared libraries
> take time. I realise "ls" is not "make", but it should give you an
> idea.
Just for fun, I did some measurements with ktrace and a static vs dynamic make.
I did 'ktrace make' and 'trace dynamicmake' ('dynamicmake' produced by running
'make NO_SHARED=no' in /usr/src/usr.bin/make), just to see where time is spent
when loading and running make in the static and dynamic cases. I did this 100
times for each version (discarding the first run) and ran through ministat
(numbers in msecs):
x static.dat
++
| x x
|
| x x x x x xx
|
| x x x x x xx x
|
|x x x x x x x x x x x x x
|
| x x x x x x x x x x x x x x x x x
|
| x x x x x x x x x x x x x x x x x x x x x x x
|
|x x x x x x x x x x x x x x x x x x x x x x x x x x x x x
x|
| |_M__A___|
|
++
N Min MaxMedian AvgStddev
x 100 2.228 2.266 2.242 2.24333 0.00794
x dynamic.dat
++
|x
|
|xx
|
| xxx x x x
|
| xxx x x xx x
|
| x x xx x x xx x x x
|
| x xx x x xx x x xx x x x x
|
|x x x xx x x x xx x x x x xx x x x x xx
|
|x xx x x x xx x x x xx x x x x xx x x x x xx x x x x xx x x x
x|
| |_M_A___|
|
++
N Min MaxMedian AvgStddev
x 100 2.648 2.691 2.6662.6669 0.00873
So the dynamic version is ca. 0.42 ms, or 16%, slower on my system.
I then compared a trace from a static and a dynamic 'make'. Both selected
traces had a running time matching the median of that run. I cut away all
common system calls etc., which resulted in just the steps involved in loading
'make' to a state where it can start executing.
In the static case, this took 0.26 ms. In the dynamic case, this took 0.57 ms,
or 0.31 ms (119%) more. The remaining ca. 0.11 ms (0.42 - 0.31) are mainly due
to the dynamic version having slightly slower IO (read() and stat()). I have no
idea why. The following are the notable steps in each version:
Static version:
* 0.09 ms spent execve'ing /usr/bin/make
* The rest is mostly sysctl calls
Dynamic version:
* 0.09 ms spent execve'ing ./dynamicmake and /libexec/ld-elf.so.1
* 0.18 ms spent loading libc.so.7 (incl. reading /etc/libmap.conf and
/var/run/ld-elf.so.hints)
* 0.11 ms spent calling sysarch(0x81,0x7fff) (static version also does
this but only uses 0.01 ms. No idea why)
* The rest is mostly sysctl and sigprocmask calls
Loading of libc.so.7 does indeed seem to be the main culprit.
Thanks,
Erik___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] Un-staticise the toolchain
On Tue, May 01, 2012 at 01:53:58PM +0200, Erik Cederstrand wrote: > Den 01/05/2012 kl. 07.52 skrev Tim Kientzle: > > > > On Apr 30, 2012, at 6:41 AM, Erik Cederstrand wrote: > >> > >> Can anyone explain to me why the dynamically linked version is > >> significantly slower? What are the extra steps involved compared to a > >> statically linked binary? > > > > At the risk of dramatically over-simplifying?. > > > > When a static binary is started by the kernel, it does the following: > > * Initializes some libc internals. > > * Calls main. > > > > When a dynamic binary is started by the kernel, it does the following: > > * Initializes some libc internals. > > * For every dynamic library referenced by this executable: > > - loads the dynamic library into memory > > - fixes up references > > * Calls main > > > > The process of loading the required libraries and fixing up references > > can be quite time-consuming. > > Thanks for the explanation. In the previous 'make index' benchmark by > Chris, make is called very often, which means the dynamic libraries > should already be loaded into memory after the first run, right? Which > means the extra time is being spent fixing up references? To an extent, yes. However the kernel still has to do some work to resolve the filename for the library to an inode, check to see if that inode is already loaded into memory, and then map the pages for the shared libraries into the new process that is requesting them. I may be misremembering (it is many many years since I had anything to do with the VM system) but I think some of that effort is non-trivial. If you want a high-level view of what goes on run ldd `which ls` check that it has libraries to load and doesn't say "not a dynamic ELF executable", and then run: ktrace ls kdump | more All the system calls related to resolving and loading shared libraries take time. I realise "ls" is not "make", but it should give you an idea. Gary ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] Un-staticise the toolchain
Den 01/05/2012 kl. 07.52 skrev Tim Kientzle: > > On Apr 30, 2012, at 6:41 AM, Erik Cederstrand wrote: >> >> Can anyone explain to me why the dynamically linked version is significantly >> slower? What are the extra steps involved compared to a statically linked >> binary? > > At the risk of dramatically over-simplifying…. > > When a static binary is started by the kernel, it does the following: > * Initializes some libc internals. > * Calls main. > > When a dynamic binary is started by the kernel, it does the following: > * Initializes some libc internals. > * For every dynamic library referenced by this executable: > - loads the dynamic library into memory > - fixes up references > * Calls main > > The process of loading the required libraries and fixing up references > can be quite time-consuming. Thanks for the explanation. In the previous 'make index' benchmark by Chris, make is called very often, which means the dynamic libraries should already be loaded into memory after the first run, right? Which means the extra time is being spent fixing up references? Erik___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] Un-staticise the toolchain
On Apr 30, 2012, at 6:41 AM, Erik Cederstrand wrote: > > Can anyone explain to me why the dynamically linked version is significantly > slower? What are the extra steps involved compared to a statically linked > binary? At the risk of dramatically over-simplifying…. When a static binary is started by the kernel, it does the following: * Initializes some libc internals. * Calls main. When a dynamic binary is started by the kernel, it does the following: * Initializes some libc internals. * For every dynamic library referenced by this executable: - loads the dynamic library into memory - fixes up references * Calls main The process of loading the required libraries and fixing up references can be quite time-consuming. Cheers, Tim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] Un-staticise the toolchain
On Sat, Apr 28, 2012 at 11:03:17AM +0100, Bob Bishop wrote: > Yes. You to have a statically linked /rescue/sh on board, so what's the > point of /bin/sh being dynamic? While you and I agree on this, the primary reason we went with a dynamically linked root was for PAM and NSS support -- which are dlopen'ed. And thus requires using a shared libc. -- -- David (obr...@freebsd.org) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] Un-staticise the toolchain
Den 26/04/2012 kl. 22.30 skrev Chris Rees: > On 26 April 2012 20:15, Matthew Seaman > wrote: >> On 26/04/2012 20:01, Chris Rees wrote: >>> 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. >> >> I don't think you can validly conclude much from just one sample of each >> type. Try repeating those tests enough that you can do some decent >> statistics. >> >> Oh, and you should probably either discard the first few results, or >> else take pains to flush[*] the buffer cache between each run, so you >> end up measuring the same thing repeatably. > > Had I done the tests the other way around, I may agree with you, but > the second test should benefit from any buffering, and it is *still* > slower. > > Look, I know it's not a perfect benchmark, it was just some food for > thought-- a difference of 10% is pretty significant, and I don't think > you can blame that on a solar flare. Can anyone explain to me why the dynamically linked version is significantly slower? What are the extra steps involved compared to a statically linked binary? Thanks, Erik___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] Un-staticise the toolchain
On Apr 28, 2012, at 3:03 AM, Bob Bishop wrote: > > 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] >>> >>> 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. > > 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 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] Un-staticise the toolchain
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] >> >> 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. 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 r...@gid.co.uk ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] Un-staticise the toolchain
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 (obr...@freebsd.org) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] Un-staticise the toolchain
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 (obr...@freebsd.org) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] Un-staticise the toolchain
On Fri, Apr 27, 2012 at 02:58:06PM +0400, Ruslan Ermilov wrote:
> 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.
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/Makefile
index 464445e..6fe22c8 100644
--- a/gnu/usr.bin/binutils/ar/Makefile
+++ b/gnu/usr.bin/binutils/ar/Makefile
@@ -1,6 +1,7 @@
# $FreeBSD$
.include "../Makefile.inc0"
+.include
.PATH: ${SRCDIR}/binutils ${SRCDIR}/binutils/doc
@@ -16,7 +17,9 @@ CFLAGS+= -D_GNU_SOURCE
CFLAGS+= -I${.CURDIR}/${RELTOP}/libbinutils
CFLAGS+= -I${SRCDIR}/binutils
CFLAGS+= -I${SRCDIR}/bfd
+.if ${MK_SHARED_TOOLCHAIN} == "no"
NO_SHARED?= yes
+.endif
DPADD= ${RELTOP}/libbinutils/libbinutils.a
DPADD+=${RELTOP}/libbfd/libbfd.a
DPADD+=${RELTOP}/libiberty/libiberty.a
diff --git a/gnu/usr.bin/binutils/as/Makefile b/gnu/usr.bin/binutils/as/Makefile
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
.PATH: ${SRCDIR}/gas ${SRCDIR}/gas/config
@@ -79,7 +80,9 @@ CFLAGS+= -D_GNU_SOURCE
CFLAGS+= -I${SRCDIR}/gas -I${SRCDIR}/bfd -I${SRCDIR}/gas/config -I${SRCDIR}
CFLAGS+= -I${.CURDIR} -I${.CURDIR}/${TARGET_CPUARCH}-freebsd
+.if ${MK_SHARED_TOOLCHAIN} == "no"
NO_SHARED?=yes
+.endif
DPADD= ${RELTOP}/libbfd/libbfd.a
DPADD+=${RELTOP}/libiberty/libiberty.a
diff --git a/gnu/usr.bin/binutils/ld/Makefile b/gnu/usr.bin/binutils/ld/Makefile
index d4420ed..ef19afa 100644
--- a/gnu/usr.bin/binutils/ld/Makefile
+++ b/gnu/usr.bin/binutils/ld/Makefile
@@ -1,6 +1,7 @@
# $FreeBSD$
.include "../Makefile.inc0"
+.include
.PATH: ${SRCDIR}/ld
@@ -34,7 +35,9 @@ CFLAGS+= -DBINDIR=\"${BINDIR}\"
-DTARGET_SYSTEM_ROOT=\"${TOOLS_PREFIX}\"
CFLAGS+= -DTOOLBINDIR=\"${TOOLS_PREFIX}/${BINDIR}/libexec\"
CFLAGS+= -D_GNU_SOURCE
CFLAGS+= -I${SRCDIR}/ld -I${SRCDIR}/bfd
+.if ${MK_SHARED_TOOLCHAIN} == "no"
NO_SHARED?= yes
+.endif
DPADD= ${RELTOP}/libbfd/libbfd.a
DPADD+=${RELTOP}/libiberty/libiberty.a
LDADD= ${DPADD}
diff --git a/gnu/usr.bin/binutils/ranlib/Makefile
b/gnu/usr.bin/binutils/ranlib/Makefile
index 8679375..052f9fe 100644
--- a/gnu/usr.bin/binutils/ranlib/Makefile
+++ b/gnu/usr.bin/binutils/ranlib/Makefile
@@ -1,6 +1,7 @@
# $FreeBSD$
.include "../Makefile.inc0"
+.include
.PATH: ${SRCDIR}/binutils ${SRCDIR}/binutils/doc
@@ -16,7 +17,9 @@ CFLAGS+= -D_GNU_SOURCE
CFLAGS+= -I${.CURDIR}/${RELTOP}/libbinutils
CFLAGS+= -I${SRCDIR}/binutils
CFLAGS+= -I${SRCDIR}/bfd
+.if ${MK_SHARED_TOOLCHAIN} == "no"
NO_SHARED?= yes
+.endif
DPADD= ${RELTOP}/libbinutils/libbinutils.a
DPADD+=${RELTOP}/libbfd/libbfd.a
DPADD+=${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= gcc
MAN= gcc.1
SRCS+= gccspec.c
+.if ${MK_SHARED_TOOLCHAIN} == "no"
NO_SHARED?=yes
+.endif
MLINKS=gcc.1 g++.1
.if ${MK_CLANG_IS_CC} == "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$
.include "../Makefile.inc"
+NO_MAN=
+.include
.PATH: ${GCCDIR}
PROG= cc1
SRCS= main.c c-parser.c c-lang.c
BINDIR=/usr/libexec
-NO_MAN=
+.if ${MK_SHARED_TOOLCHAIN} == "no"
NO_SHARED?=yes
+.endif
OBJS+= ${PROG}-checksum.o
DPADD= ${LIBBACKEND} ${LIBCPP} ${LIBDECNUMBER} ${LIBIBERTY}
diff --git a/gnu/usr.bin/cc/cc1plus/Makefile b/gnu/usr.bin/cc/cc1plus/Makefile
index 964d20f..dd3d524 100644
--- a/gnu/usr.bin/cc/cc1plus/Makefile
+++ b/gnu/usr.bin/cc/cc1plus/Makefile
@@ -1,6 +1,8 @@
# $FreeBSD$
.include "../Makefile.inc"
+NO_MAN=
+.include
.PATH: ${GCCDIR}/cp ${GCCDIR}
@@ -13,8 +15,9 @@ SRCS+=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
BINDIR=/usr/libexec
-NO_MAN=
+.if ${MK_SHARED_TOOLCHAIN} == "no"
NO_SHARED?=yes
+.endif
CFLAGS+
Re: [RFC] Un-staticise the toolchain
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. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] Un-staticise the toolchain
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 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). 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 ? N.B. I will commit the change, with defaults kept to build toolchain static, just to avoid bikeshed. pgpCSBLYyDUBp.pgp Description: PGP signature
Re: [RFC] Un-staticise the toolchain
On 26 April 2012 20:15, Matthew Seaman wrote: > On 26/04/2012 20:01, Chris Rees wrote: >> 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. > > I don't think you can validly conclude much from just one sample of each > type. Try repeating those tests enough that you can do some decent > statistics. > > Oh, and you should probably either discard the first few results, or > else take pains to flush[*] the buffer cache between each run, so you > end up measuring the same thing repeatably. Had I done the tests the other way around, I may agree with you, but the second test should benefit from any buffering, and it is *still* slower. Look, I know it's not a perfect benchmark, it was just some food for thought-- a difference of 10% is pretty significant, and I don't think you can blame that on a solar flare. Chris ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] Un-staticise the toolchain
On 26/04/2012 20:01, Chris Rees wrote: > 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. I don't think you can validly conclude much from just one sample of each type. Try repeating those tests enough that you can do some decent statistics. Oh, and you should probably either discard the first few results, or else take pains to flush[*] the buffer cache between each run, so you end up measuring the same thing repeatably. Cheers, Matthew [*] Unmount and remount /usr/ports should do that I believe. -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: [RFC] Un-staticise the toolchain
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 r...@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 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] Un-staticise the toolchain
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). ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] Un-staticise the toolchain
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 -- - d...@freebsd.org d...@db.net http://www.db.net/~db Why leave money to our children if we don't leave them the Earth? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] Un-staticise the toolchain
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 > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] Un-staticise the toolchain
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/llv
Re: [RFC] Un-staticise the toolchain
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___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] Un-staticise the toolchain
On 26 Apr 2012, at 12:38, 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. 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. 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. 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. 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___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] Un-staticise the toolchain
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 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] Un-staticise the toolchain
-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 r...@gid.co.uk -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (Darwin) iD8DBQFPmTOivMaT6aS3xb8RAi1NAJ4gyvwPgdqtZjAERJ0grBsZYo5xBQCgikdo P4LXwI1rAbA23+29XWVV8w4= =i8e3 -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[RFC] Un-staticise the toolchain
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/Makefile
index 464445e..e26be85 100644
--- a/gnu/usr.bin/binutils/ar/Makefile
+++ b/gnu/usr.bin/binutils/ar/Makefile
@@ -1,6 +1,7 @@
# $FreeBSD$
.include "../Makefile.inc0"
+.include
.PATH: ${SRCDIR}/binutils ${SRCDIR}/binutils/doc
@@ -16,7 +17,9 @@ CFLAGS+= -D_GNU_SOURCE
CFLAGS+= -I${.CURDIR}/${RELTOP}/libbinutils
CFLAGS+= -I${SRCDIR}/binutils
CFLAGS+= -I${SRCDIR}/bfd
+.if ${MK_SHARED_TOOLCHAIN} != "no"
NO_SHARED?= yes
+.endif
DPADD= ${RELTOP}/libbinutils/libbinutils.a
DPADD+=${RELTOP}/libbfd/libbfd.a
DPADD+=${RELTOP}/libiberty/libiberty.a
diff --git a/gnu/usr.bin/binutils/as/Makefile b/gnu/usr.bin/binutils/as/Makefile
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
.PATH: ${SRCDIR}/gas ${SRCDIR}/gas/config
@@ -79,7 +80,9 @@ CFLAGS+= -D_GNU_SOURCE
CFLAGS+= -I${SRCDIR}/gas -I${SRCDIR}/bfd -I${SRCDIR}/gas/config -I${SRCDIR}
CFLAGS+= -I${.CURDIR} -I${.CURDIR}/${TARGET_CPUARCH}-freebsd
+.if ${MK_SHARED_TOOLCHAIN} != "no"
NO_SHARED?=yes
+.endif
DPADD= ${RELTOP}/libbfd/libbfd.a
DPADD+=${RELTOP}/libiberty/libiberty.a
diff --git a/gnu/usr.bin/binutils/ld/Makefile b/gnu/usr.bin/binutils/ld/Makefile
index d4420ed..50d88b5 100644
--- a/gnu/usr.bin/binutils/ld/Makefile
+++ b/gnu/usr.bin/binutils/ld/Makefile
@@ -1,6 +1,7 @@
# $FreeBSD$
.include "../Makefile.inc0"
+.include
.PATH: ${SRCDIR}/ld
@@ -34,7 +35,9 @@ CFLAGS+= -DBINDIR=\"${BINDIR}\"
-DTARGET_SYSTEM_ROOT=\"${TOOLS_PREFIX}\"
CFLAGS+= -DTOOLBINDIR=\"${TOOLS_PREFIX}/${BINDIR}/libexec\"
CFLAGS+= -D_GNU_SOURCE
CFLAGS+= -I${SRCDIR}/ld -I${SRCDIR}/bfd
+.if ${MK_SHARED_TOOLCHAIN} != "no"
NO_SHARED?= yes
+.endif
DPADD= ${RELTOP}/libbfd/libbfd.a
DPADD+=${RELTOP}/libiberty/libiberty.a
LDADD= ${DPADD}
diff --git a/gnu/usr.bin/binutils/ranlib/Makefile
b/gnu/usr.bin/binutils/ranlib/Makefile
index 8679375..6d4b13e 100644
--- a/gnu/usr.bin/binutils/ranlib/Makefile
+++ b/gnu/usr.bin/binutils/ranlib/Makefile
@@ -1,6 +1,7 @@
# $FreeBSD$
.include "../Makefile.inc0"
+.include
.PATH: ${SRCDIR}/binutils ${SRCDIR}/binutils/doc
@@ -16,7 +17,9 @@ CFLAGS+= -D_GNU_SOURCE
CFLAGS+= -I${.CURDIR}/${RELTOP}/libbinutils
CFLAGS+= -I${SRCDIR}/binutils
CFLAGS+= -I${SRCDIR}/bfd
+.if ${MK_SHARED_TOOLCHAIN} != "no"
NO_SHARED?= yes
+.endif
DPADD= ${RELTOP}/libbinutils/libbinutils.a
DPADD+=${RELTOP}/libbfd/libbfd.a
DPADD+=${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= gcc
MAN= gcc.1
SRCS+= gccspec.c
+.if ${MK_SHARED_TOOLCHAIN} != "no"
NO_SHARED?=yes
+.endif
MLINKS=gcc.1 g++.1
.if ${MK_CLANG_IS_CC} == "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$
.include "../Makefile.inc"
+.include
.PATH: ${GCCDIR}
PROG= cc1
SRCS= main.c c-parser.c c-lang.c
BINDIR=/usr/libexec
-NO_MAN=
+MAN=
+.if ${MK_SHARED_TOOLCHAIN} != "no"
NO_SHARED?=yes
+.endif
OBJS+= ${PROG}-checksum.o
DPADD= ${LIBBACKEND} ${LIBCPP} ${LIBDECNUMBER} ${LIBIBERTY}
diff --git a/gnu/usr.bin/cc/cc1plus/Makefile b/gnu/usr.bin/cc/cc1plus/Makefile
index 964d20f..0bcbe61 100644
--- a/gnu/usr.bin/cc/cc1plus/Makefile
+++ b/gnu/usr.bin/cc/cc1plu
