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. pgpvnaU9s5ATe.pgp Description: PGP signature
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-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-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 bsd.own.mk
.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 bsd.own.mk
.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 bsd.own.mk
.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 bsd.own.mk
.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 bsd.own.mk
.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 bsd.own.mk
.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
[GDB follow-fork] behavior change for wait()
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
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=41042) 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
Breakpoint 1, main (argc=Error accessing memory address 0x1: Bad address.
) at fe.c:14
14 {
(gdb) n
main (argc=1, argv=0xbfbfebb4) at fe.c:19
19 if (getenv(__FE_FORKED__) != 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)
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?
--
Marcel Moolenaar
mar...@xcllnt.net
fe.c
Description: Binary data
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to freebsd-toolchain-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-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-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-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
