Re: HEADSUP: /etc/malloc.conf format change
On Wed, Apr 25, 2012 at 10:43:59AM -0700, Jason Evans wrote: On Apr 25, 2012, at 9:39 AM, Ruslan Ermilov wrote: So you removed _malloc_options that was part of the documented programming API, while some software made use of it. [...] Please explore the possibility to add backwards compatiblity for the documented API, or at the very least provide a mean to detect this otherwise disruptive and hard to detect change for a programmer. A __FreeBSD_version bump seems like a good idea to me, but adding backward compatibility for _malloc_options is questionable at best. Of the 17 options that _malloc_options supported, only 6 have directly corresponding options in malloc_conf, plus another 3 that would present strange quirks (fragile and difficult to precisely document) if an attempt were made to provide compatibility. In past iterations I was always careful to provide as much option compatibility as possible over the lifetime of each release (e.g., 'H' in RELENG_7), but individual options came and went with major releases. _malloc_options could only be pushed so far, and when it hit its breaking point I replaced it. Creaky compatibility is IMO a liability rather than an asset. In the case of nginx, it looks like a __FreeBSD_version bump is exactly what it needs. I'll try to get that done today. Well, thanks for that, and for all your hard work with malloc(). On a related note, is there any way to find all ports that refer to _malloc_options without extracting source for all of them? I considered being proactive about finding software that depends on _malloc_options, but no tractable approaches came to mind. That was already answered by Mark. -- Ruslan Ermilov r...@freebsd.org FreeBSD committer ___ 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 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..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 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..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 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..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 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..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 bsd.own.mk
.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
+++
Re: segfault in vfscanf(3): clang and __restrict usage
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 25.04.2012 21:40, Dimitry Andric wrote:
I think the easiest solution for now is to #undef __restrict at the
top of both lib/libc/stdio/vfscanf.c and lib/libc/stdio/vfwscanf.c,
then recompile and reinstall libc.
I attached a patch that removes the __restrict keyword in the
convert_* functions because I believe it's incorrect.
In vfscanf.c, I kept the last one in parseint() because I believe it's
correct: the restricted pointer is used to initialized another one and
comparisons are made only between those two pointers. But I didn't
check if clang optimized out the comparisons. What do you think about
the correctness here?
We can't remove it in vfwscanf(), vfwscanf_l() and __vfwscanf()
(vfwscanf.c) because it's required by the vfwscanf(3) API.
The patch also removes some trailing whitespaces while here.
I'm rebuilding world with this patch and will check that cmake is
working again (the program which shows segfaults for me).
Boris, could you please test it and tell me if cupsd works again for
you too? You just need to rebuild/reinstall the libc, not cups.
Dimitry, thank you for the reporting the problem to LLVM!
- --
Jean-Sébastien Pédron
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk+ZGDoACgkQa+xGJsFYOlOA4ACdH7vH4XfjH6nxcV/axmAYKUKq
8hoAoMrfly9RkUL0UKSKsmbxIiBz2YZy
=GFTc
-END PGP SIGNATURE-
diff --git a/lib/libc/stdio/vfscanf.c b/lib/libc/stdio/vfscanf.c
index 6a6b19c..5316a7c 100644
--- a/lib/libc/stdio/vfscanf.c
+++ b/lib/libc/stdio/vfscanf.c
@@ -125,7 +125,7 @@ static const mbstate_t initial_mbs;
*/
static __inline int
-convert_char(FILE *fp, char * __restrict p, int width)
+convert_char(FILE *fp, char * p, int width)
{
int n, nread;
@@ -152,7 +152,7 @@ convert_char(FILE *fp, char * __restrict p, int width)
nread += sum;
} else {
size_t r = __fread(p, 1, width, fp);
-
+
if (r == 0)
return (-1);
nread += r;
@@ -205,7 +205,7 @@ convert_wchar(FILE *fp, wchar_t *wcp, int width)
}
static __inline int
-convert_ccl(FILE *fp, char * __restrict p, int width, const char *ccltab)
+convert_ccl(FILE *fp, char * p, int width, const char *ccltab)
{
char *p0;
int n;
@@ -304,7 +304,7 @@ convert_wccl(FILE *fp, wchar_t *wcp, int width, const char
*ccltab)
}
static __inline int
-convert_string(FILE *fp, char * __restrict p, int width)
+convert_string(FILE *fp, char * p, int width)
{
char *p0;
int n;
@@ -467,7 +467,7 @@ parseint(FILE *fp, char * __restrict buf, int width, int
base, int flags)
goto ok;
}
break;
-
+
/*
* x ok iff flag still set 2nd char (or 3rd char if
* we have a sign).
diff --git a/lib/libc/stdio/vfwscanf.c b/lib/libc/stdio/vfwscanf.c
index 6b4d8c5..9d628b0 100644
--- a/lib/libc/stdio/vfwscanf.c
+++ b/lib/libc/stdio/vfwscanf.c
@@ -138,7 +138,7 @@ static const mbstate_t initial_mbs;
*/
static __inline int
-convert_char(FILE *fp, char * __restrict mbp, int width, locale_t locale)
+convert_char(FILE *fp, char * mbp, int width, locale_t locale)
{
mbstate_t mbs;
size_t nconv;
@@ -192,7 +192,7 @@ convert_wchar(FILE *fp, wchar_t *wcp, int width, locale_t
locale)
}
static __inline int
-convert_ccl(FILE *fp, char * __restrict mbp, int width, const struct ccl *ccl,
+convert_ccl(FILE *fp, char * mbp, int width, const struct ccl *ccl,
locale_t locale)
{
mbstate_t mbs;
@@ -261,7 +261,7 @@ convert_wccl(FILE *fp, wchar_t *wcp, int width, const
struct ccl *ccl,
}
static __inline int
-convert_string(FILE *fp, char * __restrict mbp, int width, locale_t locale)
+convert_string(FILE *fp, char * mbp, int width, locale_t locale)
{
mbstate_t mbs;
size_t nconv;
@@ -407,7 +407,7 @@ parseint(FILE *fp, wchar_t *buf, int width, int base, int
flags,
goto ok;
}
break;
-
+
/*
* x ok iff flag still set 2nd char (or 3rd char if
* we have a sign).
___
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
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
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
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 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
no ptX device found
Hi all, On current, till about 3 months, no pty device is created. i see only a pts[0] in dev. screen (4.0.1, not higher) does not find any pty device. How can i create at least one? my ttys seems to have no effect. I am pretty sure i miss somemthing. In another hand, i see nothing in the man pages on this topic. Thanks in advance for your help. Best regards Raoul rm...@free.fr ___ 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 utis...@gmail.com wrote: On Apr 26, 2012 10:36 AM, Konstantin Belousov kostik...@gmail.com 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 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
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 Apr 26, 2012 2:42 PM, Ruslan Ermilov r...@freebsd.org 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 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 26 April 2012 20:15, Matthew Seaman m.sea...@infracaninophile.co.uk 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: segfault in vfscanf(3): clang and __restrict usage
26.04.2012 13:41, Jean-Sébastien Pédron пишет: Boris, could you please test it and tell me if cupsd works again for you too? You just need to rebuild/reinstall the libc, not cups. I've rebuild the world (because I had to use gcc-built world for obvious reason) and now smartd works (can't test cupsd for now). BTW, the port devel/ORBit2 which segfaulted both with clang and gcc is built fine now. Thanks! -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve ___ 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
updating from r231158 to 234465: mounting from ufs:/dev/ad4s1a failed with error 19
I was updating from r231158 to 234465 (amd64 laptop Compaq 6715s), and I think I must've messed someting up in the kernel config. Now I get build error, panic of a loader error, depending on which kernel I build. * If I build GENERIC, I get: (transcribed by hand) mountroot: waiting for device /dev/ad4s1a Mounting from ufs:/dev/ad4s1a failed with error 19. mountroot ? List of GEOM managed disk devices: cd0 mountroot The device is certainly correct in r231158: BUZI df Filesystem 512-blocks UsedAvail Capacity Mounted on /dev/ad4s1a 101554068 46474368 4695537650%/ devfs220 100%/dev BUZI * If I add device atadisk to GENERIC, then I get this linking error: linking kernel.debug ata-disk.o: In function `ad_init': /usr/src/sys/dev/ata/ata-disk.c:397: undefined reference to `ata_setmode' /usr/src/sys/dev/ata/ata-disk.c:405: undefined reference to `ata_wc' /usr/src/sys/dev/ata/ata-disk.c:406: undefined reference to `ata_controlcmd' /usr/src/sys/dev/ata/ata-disk.c:408: undefined reference to `ata_controlcmd' /usr/src/sys/dev/ata/ata-disk.c:401: undefined reference to `ata_controlcmd' /usr/src/sys/dev/ata/ata-disk.c:415: undefined reference to `ata_controlcmd' ata-disk.o: In function `ad_shutdown': /usr/src/sys/dev/ata/ata-disk.c:204: undefined reference to `ata_controlcmd' ata-disk.o: In function `ad_detach': /usr/src/sys/dev/ata/ata-disk.c:190: undefined reference to `ata_fail_requests' ata-disk.o: In function `ad_dump': /usr/src/sys/dev/ata/ata-disk.c:370: undefined reference to `ata_drop_requests' /usr/src/sys/dev/ata/ata-disk.c:378: undefined reference to `ata_controlcmd' ata-disk.o: In function `ad_attach': /usr/src/sys/dev/ata/ata-disk.c:115: undefined reference to `ata_setmax' ata-disk.o: In function `ad_describe': /usr/src/sys/dev/ata/ata-disk.c:555: undefined reference to `ata_satarev2str' /usr/src/sys/dev/ata/ata-disk.c:555: undefined reference to `ata_unit2str' ata-disk.o: In function `ad_set_geometry': /usr/src/sys/dev/ata/ata-disk.c:492: undefined reference to `ata_queue_request' /usr/src/sys/dev/ata/ata-disk.c:511: undefined reference to `ata_queue_request' /usr/src/sys/dev/ata/ata-disk.c:516: undefined reference to `ata_getparam' ata-disk.o: In function `ad_spindown': /usr/src/sys/dev/ata/ata-disk.c:250: undefined reference to `ata_queue_request' ata-disk.o: In function `ad_ioctl': /usr/src/sys/dev/ata/ata-disk.c:354: undefined reference to `ata_device_ioctl' ata-disk.o: In function `ad_strategy': /usr/src/sys/dev/ata/ata-disk.c:335: undefined reference to `ata_queue_request' atapi-cd.o: In function `acd_reinit': /usr/src/sys/dev/ata/atapi-cd.c:166: undefined reference to `ata_setmode' atapi-cd.o: In function `acd_shutdown': /usr/src/sys/dev/ata/atapi-cd.c:152: undefined reference to `ata_controlcmd' atapi-cd.o: In function `acd_geom_detach': /usr/src/sys/dev/ata/atapi-cd.c:199: undefined reference to `ata_fail_requests' atapi-cd.o: In function `acd_test_ready': /usr/src/sys/dev/ata/atapi-cd.c:1693: undefined reference to `ata_atapicmd' atapi-cd.o: In function `acd_mode_select': /usr/src/sys/dev/ata/atapi-cd.c:1619: undefined reference to `ata_atapicmd' atapi-cd.o: In function `acd_mode_sense': /usr/src/sys/dev/ata/atapi-cd.c:1609: undefined reference to `ata_atapicmd' atapi-cd.o: In function `acd_pause_resume': /usr/src/sys/dev/ata/atapi-cd.c:1599: undefined reference to `ata_atapicmd' atapi-cd.o: In function `acd_start_stop': /usr/src/sys/dev/ata/atapi-cd.c:1590: undefined reference to `ata_atapicmd' atapi-cd.o:/usr/src/sys/dev/ata/atapi-cd.c:1581: more undefined references to `ata_atapicmd' foll atapi-cd.o: In function `acd_get_progress': /usr/src/sys/dev/ata/atapi-cd.c:1236: undefined reference to `ata_queue_request' atapi-cd.o: In function `acd_strategy': /usr/src/sys/dev/ata/atapi-cd.c:889: undefined reference to `ata_queue_request' atapi-cd.o: In function `acd_geom_access': /usr/src/sys/dev/ata/atapi-cd.c:704: undefined reference to `ata_queue_request' atapi-cd.o: In function `acd_read_format_caps': /usr/src/sys/dev/ata/atapi-cd.c:1671: undefined reference to `ata_atapicmd' atapi-cd.o: In function `acd_geom_ioctl': /usr/src/sys/dev/ata/atapi-cd.c:680: undefined reference to `ata_device_ioctl' atapi-cd.o: In function `acd_format': /usr/src/sys/dev/ata/atapi-cd.c:1682: undefined reference to `ata_atapicmd' atapi-cd.o: In function `acd_report_key': /usr/src/sys/dev/ata/atapi-cd.c:1336: undefined reference to `ata_atapicmd' atapi-cd.o: In function `acd_read_track_info': /usr/src/sys/dev/ata/atapi-cd.c:1206: undefined reference to `ata_atapicmd' atapi-cd.o: In function `acd_init_writer': /usr/src/sys/dev/ata/atapi-cd.c:1056: undefined reference to `ata_atapicmd' /usr/src/sys/dev/ata/atapi-cd.c:1059: undefined reference to `ata_atapicmd' atapi-cd.o:/usr/src/sys/dev/ata/atapi-cd.c:1086: more undefined references to
