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 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 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
Re: [workaroud/fix for] buildworld fails on FreeBSD 7.x for HEAD from 19.04.2012
On 2012.04.22 21:07, Garrett Cooper wrote:
On Apr 22, 2012, at 10:34 AM, Dimitry Andric wrote:
Well, I wouldn't want to run autoconf during build, firstly because it
is horribly slow, and second because the results will be less
predictable. Maybe during the bootstrap stage, it would be acceptable.
Sure -- that seems reasonable.
But even then, one of the configure scripts could fail due to too-old
system components, and you would be SOL.
… but it would be a step forward from where things are currently at. I'm not sure how
well tested source upgrade paths are, but being able to upgrade from the
lowest supported version to the latest supported version, then upgrading to CURRENT (at
the very least) would be nice.
Usually, if something is arch-dependent in a config.h file, we simply
surround it with #ifdefs.
Makes sense (assumption being that it can be controlled via the
config.h/configure.{ac,in} file). However, jemalloc recently disproved this_.
Apparently the file(1) build needs a 'mkmagic' tool, which generates
.mgc files (the 'compiled' version of magic files). This requirement
was originally added in r81845, more than 10 years ago.
I tested out removing libmagic from Makefile.inc1 and see that there's some
dependency magic going on there where building the library failed.
Yes, it might work, but there is no guarantee. I'm not sure if there is
enough incentive to change this policy. It would potentially require a
lot effort to make it always work.
Understood and I guess the ownness is upon the stakeholders to fix this, but
there are a lot of companies that depend on things like this working (at least
to reduce pain when doing source upgrades). This would probably be less of an
issue for developers that use freebsd-update or for companies that roll their
own freebsd-update (and servers). I have yet to run into a company that does
this though (not saying there aren't groups that could or do do this, but it's
not the standard path).
I wasn't aware of any chroot hackery?
A publicly available example is available in FreeNAS (
http://freenas.svn.sourceforge.net/viewvc/freenas?view=revisionrevision=8193
); the hangup is building packages for a target system that doesn't match the build
host.
Cheers!
-Garrett
Hello!
I have prepared workaround/fix for this issue. It has been tested on FreeBSD 7.3
and 9.0 (both RELEASE) with good results: world build finishes OK. I attach the
patch in case someone else is hit by this issue. Feel free to use it.
Thanks for all suggestions and comments.
Regards,
Jan Sieka
diff --git a/lib/libmagic/Makefile b/lib/libmagic/Makefile
index 9c35c35..e9b8240 100644
--- a/lib/libmagic/Makefile
+++ b/lib/libmagic/Makefile
@@ -10,9 +10,16 @@ DPADD= ${LIBZ}
LDADD= -lz
MAN= libmagic.3 magic.5
+HOSTOSRELDATE!=echo ${VERSION} | cut -d -f 4
+
+.if ${HOSTOSRELDATE} 80
+GETLINE_C= getline.c
+.else
+GETLINE_C=
+.endif
SRCS= apprentice.c apptype.c ascmagic.c cdf.c cdf_time.c compress.c \
encoding.c fsmagic.c funcs.c \
- is_tar.c magic.c print.c readcdf.c readelf.c softmagic.c
+ is_tar.c magic.c print.c readcdf.c readelf.c softmagic.c ${GETLINE_C}
INCS= magic.h
MAGICPATH?=/usr/share/misc
@@ -39,7 +46,8 @@ magic.mgc: mkmagic magic
CLEANFILES+= mkmagic
build-tools: mkmagic
-mkmagic: apprentice.c funcs.c magic.c print.c
+
+mkmagic: apprentice.c funcs.c magic.c print.c ${GETLINE_C}
${CC} ${CFLAGS} -DCOMPILE_ONLY ${LDFLAGS} -o ${.TARGET} ${.ALLSRC}
FILEVER!= awk '$$1 == \#define $$2 == VERSION { print $$3; exit }' \
diff --git a/lib/libmagic/config.h b/lib/libmagic/config.h
index 06ed4ec..3fe103e 100644
--- a/lib/libmagic/config.h
+++ b/lib/libmagic/config.h
@@ -39,7 +39,11 @@
#define HAVE_FSEEKO 1
/* Define to 1 if you have the `getline' function. */
-#define HAVE_GETLINE 1
+#if (__FreeBSD_version = 80)
+#defineHAVE_GETLINE 1
+#else
+#defineHAVE_GETLINE 0
+#endif
/* Define to 1 if you have the getopt.h header file. */
#define HAVE_GETOPT_H 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: updating from r231158 to 234465: mounting from ufs:/dev/ad4s1a failed with error 19
On Thursday, April 26, 2012 6:42:15 pm Anton Shterenlikht wrote: 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 Hmm, so GENERIC is not finding ad4. Can you look in the dmesg (using scroll-lock) to see if GENERIC finds your ATA controller ok? 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: Yes, you aren't supposed to use 'atadisk' with ATA_CAM. See the UPDATING entry 20110424 for more details on that. However, can you obtain a verbose dmesg from your old kernel? -- 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
compiling world fails in === usr.sbin/dnssec-revoke (all) with 9.0 from today
Hi, I just downloaded the sources for 9.0 stable and got this error while compiling world: === usr.sbin/dnssec-revoke (all) cc -O2 -pipe -DVERSION='9.8.1-P1' -DHAVE_CONFIG_H -D_REENTRANT -D_THREAD_SAFE -DWANT_IPV6 -DOPENSSL -DUSE_MD5 -DNS_LOCALSTATEDIR='/var' -DNS_SYSCONFDIR='/etc/namedb' -DNAMED_CONFFILE='/etc/namedb/named.conf' -DRNDC_CONFFILE='/etc/namedb/rndc.conf' -DRNDC_KEYFILE='/etc/namedb/rndc.key' -I/usr/src/usr.sbin/dnssec-revoke/../../lib/bind -I/usr/src/usr.sbin/dnssec-revoke/../../contrib/bind9/lib/bind9/include -I/usr/src/usr.sbin/dnssec-revoke/../../contrib/bind9/lib/dns/include/dst -I/usr/src/usr.sbin/dnssec-revoke/../../contrib/bind9/lib/dns/include -I/usr/src/usr.sbin/dnssec-revoke/../../lib/bind/dns -I/usr/src/usr.sbin/dnssec-revoke/../../contrib/bind9/lib/isccc/include -I/usr/src/usr.sbin/dnssec-revoke/../../contrib/bind9/lib/isccfg/include -I/usr/src/usr.sbin/dnssec-revoke/../../contrib/bind9/lib/isc/unix/include -I/usr/src/usr.sbin/dnssec-revoke/../../contrib/bind9/lib/isc/pthreads/include -I/usr/src/usr.sbin/dnssec-revoke/../../contrib/bind9/lib/isc/include -I/usr/src/usr.sbin/dnssec-revoke/../../lib/bind/isc -I/usr/src/usr.sbin/dnssec-revoke/../../contrib/bind9/lib/lwres/unix/include -I/usr/src/usr.sbin/dnssec-revoke/../../contrib/bind9/lib/lwres/include -I/usr/src/usr.sbin/dnssec-revoke/../../lib/bind/lwres -I/usr/src/usr.sbin/dnssec-revoke/../../contrib/bind9/bin/dnssec/unix/include -I/usr/src/usr.sbin/dnssec-revoke/../../contrib/bind9/bin/dnssec/include -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /usr/src/usr.sbin/dnssec-revoke/../../contrib/bind9/bin/dnssec/dnssec-revoke.c cc1: warnings being treated as errors /usr/src/usr.sbin/dnssec-revoke/../../contrib/bind9/bin/dnssec/dnssec-revoke.c: In function 'main': /usr/src/usr.sbin/dnssec-revoke/../../contrib/bind9/bin/dnssec/dnssec-revoke.c:194: warning: implicit declaration of function 'dst_key_rid' *** [dnssec-revoke.o] Error code 1 Stop in /usr/src/usr.sbin/dnssec-revoke. *** [all] Error code 1 The machine: FreeBSD X220.ovitrap.com 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 It is an empty machine just installed from a thumb drive with nothing installed on it yet. Should I treat the warnings as warnings and not as errors? Erich ___ 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
Mounting removable devices
Dear All ,
To mount removable devices , a user ( NOT root ) requires the following
parameter
vfs.usermount=1
in
/etc/sysctl.conf
.
A warning is specified in
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/usb-disks.html
about its security vulnerabilities .
Instead of using
vfs.usermount=1
for this purpose , a new parameter may be defined as follows :
vfs.removablemount=1
.
If
vfs.usermount=1
is found in /etc/sysctl.conf , then
vfs.removablemount=1
may be assumed , if it is not present in /etc/sysctl.conf .
I prefer separate usage :
vfs.usermount=1 for ONLY fixed devices ,
vfs.removablemount=1 for ONLY removable devices .
A developer knowing the usage of vfs.usermount in FreeBSD sources
may easily implement vfs.removablemount .
Such an implementation will fix security vulnerability caused by
using vfs.usermount=1 for
removable devices .
Sometimes , it may be necessary to restrict mount of removable devices
due to security requirements . Therefore , supplying a vfs.removablemount=
{ 0 or 1 }
may be a useful improvement .
I am NOT able to supply a patch about this because I do NOT know sources
sufficiently well .
Thank you very much .
Mehmet Erol Sanliturk
___
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: compiling world fails with 9.0 and 10.0 from today (28.04)
Hi, I moved this back to current. See the reason below. I was a bit confused as I tried to install 9.0 and 10.0 but posted the 9.0 question to the 10.0 list. Here is the 10.0 question. On Saturday 28 April 2012 06:07:28 David Wolfskill wrote: On Fri, Apr 27, 2012 at 11:08:22PM +0700, Erich Dollansky wrote: I just downloaded the sources for 9.0 stable and got this error while compiling world: You posted this to freebsd-current@ ??!? FreeBSD 9.x hasn't been CURRENT since 25 Sep 2011. Further, I most recently built stable/9 at r234728 -- without issue. this is what I have gathered from the list and the Internet. It should work but it does not in my case. Let me first explain what I did. I downloaded the image for the thumb drive for 9.0. I then inserted a brand new disk in my notebook and installed FreeBSD 9.0 on it. So, the machine running the compilations is: FreeBSD X220.ovitrap.com 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 I downloaded then the most current sources for 9.0 and 10.0 and left the Internet for some reason. During travelling, I tried to compile both kernels and both failed. FreeBSD 10.0 gives me this error message: === kerberos5/tools (obj,depend,all) === kerberos5/tools/make-print-version (obj) cd: /usr/src/kerberos5/tools/make-print-version: No such file or directory *** [obj] Error code 2 Stop in /usr/src/kerberos5/tools. *** [build-tools] Error code 1 Where can I find information about 10.0 to enable me to fix this myself? I have the feeling that I have missed something very simple in the configuration process. Erich ___ 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: compiling world fails with 9.0 and 10.0 from today (28.04)
On Sat, Apr 28, 2012 at 08:25:37AM +0700, Erich Dollansky wrote: ... FreeBSD 10.0 gives me this error message: === kerberos5/tools (obj,depend,all) === kerberos5/tools/make-print-version (obj) cd: /usr/src/kerberos5/tools/make-print-version: No such file or directory *** [obj] Error code 2 Stop in /usr/src/kerberos5/tools. *** [build-tools] Error code 1 Where can I find information about 10.0 to enable me to fix this myself? What command(s) did you use? What was your current working directory at the time? Have you reviewed /usr/src/UPDATING? Near the end of that file, there is a list of commands to use to build from sources. Scan for COMMON ITEMS. I have the feeling that I have missed something very simple in the configuration process. You would hardly be the first to encounter such a thing. :-} Peace, david -- David H. Wolfskill da...@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpZJWum0PXue.pgp Description: PGP signature
Re: compiling world fails with 9.0 and 10.0 from today (28.04)
Hi, On Saturday 28 April 2012 08:31:55 David Wolfskill wrote: On Sat, Apr 28, 2012 at 08:25:37AM +0700, Erich Dollansky wrote: ... FreeBSD 10.0 gives me this error message: === kerberos5/tools (obj,depend,all) === kerberos5/tools/make-print-version (obj) cd: /usr/src/kerberos5/tools/make-print-version: No such file or directory *** [obj] Error code 2 Stop in /usr/src/kerberos5/tools. *** [build-tools] Error code 1 Where can I find information about 10.0 to enable me to fix this myself? What command(s) did you use? What was your current working directory at the time? I use the following commands to do the compilation: cd /usr/src /usr/bin/nice -n 20 make buildworld Have you reviewed /usr/src/UPDATING? Near the end of that file, there is a list of commands to use to build from sources. Scan for COMMON ITEMS. Do you mean this one? make kernel-toolchain make -DALWAYS_CHECK_MAKE buildkernel KERNCONF=YOUR_KERNEL_HERE make -DALWAYS_CHECK_MAKE installkernel KERNCONF=YOUR_KERNEL_HERE Isn't this the next step after building the world? I have the feeling that I have missed something very simple in the configuration process. You would hardly be the first to encounter such a thing. :-} I also think so. I am currently downloading the 9.0 sources into an empty source tree on a 8.3 machine to see what happens there. I extra did not copy the data from 9.0 machine to avoid any problem being moved over to the other working machine. Erich ___ 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: compiling world fails with 9.0 and 10.0 from today (28.04)
On Sat, Apr 28, 2012 at 08:50:47AM +0700, Erich Dollansky wrote: ... I use the following commands to do the compilation: cd /usr/src /usr/bin/nice -n 20 make buildworld OK. That should build the userland OK. Have you reviewed /usr/src/UPDATING? Near the end of that file, there is a list of commands to use to build from sources. Scan for COMMON ITEMS. Do you mean this one? make kernel-toolchain make -DALWAYS_CHECK_MAKE buildkernel KERNCONF=YOUR_KERNEL_HERE make -DALWAYS_CHECK_MAKE installkernel KERNCONF=YOUR_KERNEL_HERE Isn't this the next step after building the world? No; I was referring to the part with the sub-heading To rebuild everything and install it on the current system. or To upgrade in-place from 8.x-stable to current depending on whether you're tring to update release/9.0 to stable/9 or release/9.0 to head (for example). ... I am currently downloading the 9.0 sources into an empty source tree on a 8.3 machine to see what happens there. Note that this is also an upgrade. Peace, david -- David H. Wolfskill da...@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgphMU1kVX0dX.pgp Description: PGP signature
Re: compiling world fails with 9.0 and 10.0 from today (28.04)
Hi, On Saturday 28 April 2012 08:59:15 David Wolfskill wrote: On Sat, Apr 28, 2012 at 08:50:47AM +0700, Erich Dollansky wrote: ... I use the following commands to do the compilation: cd /usr/src /usr/bin/nice -n 20 make buildworld OK. That should build the userland OK. this is what I expected. I simply follow blindly what is written here: Have you reviewed /usr/src/UPDATING? Near the end of that file, there is a list of commands to use to build from sources. Scan for COMMON ITEMS. Do you mean this one? make kernel-toolchain make -DALWAYS_CHECK_MAKE buildkernel KERNCONF=YOUR_KERNEL_HERE make -DALWAYS_CHECK_MAKE installkernel KERNCONF=YOUR_KERNEL_HERE Isn't this the next step after building the world? No; I was referring to the part with the sub-heading To rebuild everything and install it on the current system. or To upgrade in-place from 8.x-stable to current depending on whether you're tring to update release/9.0 to stable/9 or release/9.0 to head (for example). ... I am currently downloading the 9.0 sources into an empty source tree on a 8.3 machine to see what happens there. Note that this is also an upgrade. Peace, david -- David H. Wolfskillda...@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. ___ 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: compiling world fails with 9.0 and 10.0 from today (28.04)
Hi, sorry, I just have sent this out before finishing it. On Saturday 28 April 2012 08:59:15 David Wolfskill wrote: On Sat, Apr 28, 2012 at 08:50:47AM +0700, Erich Dollansky wrote: ... I use the following commands to do the compilation: cd /usr/src /usr/bin/nice -n 20 make buildworld OK. That should build the userland OK. I use what is written here as my standard procedure: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html No; I was referring to the part with the sub-heading To rebuild everything and install it on the current system. or To upgrade in-place from 8.x-stable to current depending on whether you're tring to update release/9.0 to stable/9 or release/9.0 to head (for example). I thought the procedure above covers both. It just contains some steps I would not need recompiling 8.3 after a few days with some updates. ... I am currently downloading the 9.0 sources into an empty source tree on a 8.3 machine to see what happens there. Note that this is also an upgrade. This should not matter with the procedure as described above. Right? Thanks for you help. Erich Peace, david -- David H. Wolfskillda...@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. ___ 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: [workaroud/fix for] buildworld fails on FreeBSD 7.x for HEAD from 19.04.2012
On Fri, Apr 27, 2012 at 02:05:37PM +0200, Jan Sieka wrote:
--- a/lib/libmagic/Makefile
+++ b/lib/libmagic/Makefile
@@ -10,9 +10,16 @@ DPADD= ${LIBZ}
LDADD= -lz
MAN= libmagic.3 magic.5
+HOSTOSRELDATE!= echo ${VERSION} | cut -d -f 4
$ cd lib/libmagic
$ make -V VERSION
{empty}
Where is VERSION set?
+.if ${HOSTOSRELDATE} 80
+GETLINE_C= getline.c
+.else
+GETLINE_C=
+.endif
SRCS=apprentice.c apptype.c ascmagic.c cdf.c cdf_time.c compress.c \
encoding.c fsmagic.c funcs.c \
- is_tar.c magic.c print.c readcdf.c readelf.c softmagic.c
+ is_tar.c magic.c print.c readcdf.c readelf.c softmagic.c ${GETLINE_C}
Just
.if ${HOSTOSRELDATE} 80
GETLINE_C= getline.c
.endif
is shorter.
Also r189136 (which added getline(3)) bumped __FreeBSD_version from
800066 to 800067. So your patch is broken for some systems. Getting
this right is one reason I'm loath to carry around this type of hack
in -CURRENT.
--- a/lib/libmagic/config.h
+++ b/lib/libmagic/config.h
/* Define to 1 if you have the `getline' function. */
-#define HAVE_GETLINE 1
+#if (__FreeBSD_version = 80)
Where is __FreeBSD_version getting set?
+#else
+#define HAVE_GETLINE 0
+#endif
You've basically defined HAVE_GETLINE always as 0.
--
-- 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 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
