r264702: kldxref: /boot/modules/kldxref.core: too many sections
On FreeBSD 11.0-CURRENT #0 r264702: Sun Apr 20 23:56:04 CEST 2014 amd64 I receive this mysterious message several times when compiling a new kernel an automatically build virtualbox-ose-kmod-4.3.10. What is this supposed to mean? ===> Deinstalling for emulators/virtualbox-ose-kmod ===> Deinstalling pkg-static: You are trying to delete package(s) which has dependencies that are still required: emulators/virtualbox-ose-kmod: emulators/virtualbox-ose ... delete these packages anyway in forced mode Deinstallation has been requested for the following 1 packages: virtualbox-ose-kmod-4.3.10 The deinstallation will free 394 KB [1/1] Deleting virtualbox-ose-kmod-4.3.10... virtualbox-ose-kmod-4.3.10 is required by: virtualbox-ose-4.3.10, deleting anyway kldxref: /boot/modules/kldxref.core: too many sections kldxref: /boot/modules/kldxref.core: too many sections kldxref: /boot/modules/kldxref.core: too many sections kldxref: /boot/modules/kldxref.core: too many sections kldxref: /boot/modules/kldxref.core: too many sections kldxref: /boot/modules/kldxref.core: too many sections kldxref: Skipping /boot/modules/kldxref.core: not dynamically-linked done ===> Installing for virtualbox-ose-kmod-4.3.10 ===> Registering installation for virtualbox-ose-kmod-4.3.10 kldxref: /boot/modules/kldxref.core: too many sections kldxref: /boot/modules/kldxref.core: too many sections kldxref: /boot/modules/kldxref.core: too many sections kldxref: /boot/modules/kldxref.core: too many sections kldxref: /boot/modules/kldxref.core: too many sections kldxref: /boot/modules/kldxref.core: too many sections kldxref: Skipping /boot/modules/kldxref.core: not dynamically-linked Installing virtualbox-ose-kmod-4.3.10... done signature.asc Description: PGP signature
Re: r264702: kldxref: /boot/modules/kldxref.core: too many sections
On Mon, Apr 21, 2014 at 09:03:20AM +0200, O. Hartmann wrote: > On FreeBSD 11.0-CURRENT #0 r264702: Sun Apr 20 23:56:04 CEST 2014 amd64 > > I receive this mysterious message several times when compiling a new kernel an > automatically build virtualbox-ose-kmod-4.3.10. What is this supposed to mean? Most likely, it means that kldxref(8) dumped core in your /boot/kernel directory. If you do not need the core file, remove it. > > ===> Deinstalling for emulators/virtualbox-ose-kmod > ===> Deinstalling > pkg-static: You are trying to delete package(s) which has dependencies that > are still > required: emulators/virtualbox-ose-kmod: emulators/virtualbox-ose > ... delete these packages anyway in forced mode > Deinstallation has been requested for the following 1 packages: > > virtualbox-ose-kmod-4.3.10 > > The deinstallation will free 394 KB > [1/1] Deleting virtualbox-ose-kmod-4.3.10... > virtualbox-ose-kmod-4.3.10 is required by: virtualbox-ose-4.3.10, deleting > anyway > kldxref: /boot/modules/kldxref.core: too many sections > kldxref: /boot/modules/kldxref.core: too many sections > kldxref: /boot/modules/kldxref.core: too many sections > kldxref: /boot/modules/kldxref.core: too many sections > kldxref: /boot/modules/kldxref.core: too many sections > kldxref: /boot/modules/kldxref.core: too many sections > kldxref: Skipping /boot/modules/kldxref.core: not dynamically-linked > done > ===> Installing for virtualbox-ose-kmod-4.3.10 > ===> Registering installation for virtualbox-ose-kmod-4.3.10 > kldxref: /boot/modules/kldxref.core: too many sections > kldxref: /boot/modules/kldxref.core: too many sections > kldxref: /boot/modules/kldxref.core: too many sections > kldxref: /boot/modules/kldxref.core: too many sections > kldxref: /boot/modules/kldxref.core: too many sections > kldxref: /boot/modules/kldxref.core: too many sections > kldxref: Skipping /boot/modules/kldxref.core: not dynamically-linked > Installing virtualbox-ose-kmod-4.3.10... done pgpHcKR_GWWSA.pgp Description: PGP signature
[head tinderbox] failure on arm/arm
TB --- 2014-04-21 07:50:28 - tinderbox 2.21 running on freebsd-current.sentex.ca TB --- 2014-04-21 07:50:28 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-04-21 07:50:28 - starting HEAD tinderbox run for arm/arm TB --- 2014-04-21 07:50:28 - cleaning the object tree TB --- 2014-04-21 07:51:08 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-04-21 07:51:12 - At svn revision 264720 TB --- 2014-04-21 07:51:13 - building world TB --- 2014-04-21 07:51:13 - CROSS_BUILD_TESTING=YES TB --- 2014-04-21 07:51:13 - MAKEOBJDIRPREFIX=/obj TB --- 2014-04-21 07:51:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-04-21 07:51:13 - SRCCONF=/dev/null TB --- 2014-04-21 07:51:13 - TARGET=arm TB --- 2014-04-21 07:51:13 - TARGET_ARCH=arm TB --- 2014-04-21 07:51:13 - TZ=UTC TB --- 2014-04-21 07:51:13 - __MAKE_CONF=/dev/null TB --- 2014-04-21 07:51:13 - cd /src TB --- 2014-04-21 07:51:13 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Apr 21 07:51:20 UTC 2014 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/arm.arm/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -c /src/lib/libc/uuid/uuid_create_nil.c -o! uuid_create_nil.o cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/arm.arm/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -c /src/lib/libc/uuid/uuid_equal.c -o uuid! _equal.o cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/arm.arm/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -c /src/lib/libc/uuid/uuid_from_string.c -! o uuid_from_string.o cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/arm.arm/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORT
Re: UFS lock order reversal stack trace with r264677 on i386
On Sat, 19 Apr 2014, R. Tyler Croy wrote: I've noticed this as of late on my i386 -CURRENT Thinkpad T43 when I perform some file operations, but an exact reproduction case I've not yet stumbled upon: Apr 20 01:29:32 lemon kernel: lock order reversal: Apr 20 01:29:32 lemon kernel: 1st 0xc5832358 bufwait (bufwait) @ /usr/home/tyler/source/github/freebsd/sys/kern/vfs_bio.c:3081 Apr 20 01:29:32 lemon kernel: 2nd 0xc6f1d600 dirhash (dirhash) @ /usr/home/tyler/source/github/freebsd/sys/ufs/ufs/ufs_dirhash.c:284 [...] Apr 20 01:29:54 lemon kernel: lock order reversal: Apr 20 01:29:54 lemon kernel: 1st 0xc699e388 ufs (ufs) @ /usr/home/tyler/source/github/freebsd/sys/kern/vfs_subr.c:2101 Apr 20 01:29:54 lemon kernel: 2nd 0xc5859e98 bufwait (bufwait) @ /usr/home/tyler/source/github/freebsd/sys/ufs/ffs/ffs_vnops.c:262 Apr 20 01:29:54 lemon kernel: 3rd 0xc7d27c68 ufs (ufs) @ /usr/home/tyler/source/github/freebsd/sys/kern/vfs_subr.c:2101 These are "well known", #261 and #285 at http://sources.zabbadoz.net/freebsd/lor.html . -Ben Kaduk ___ 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"
Build failures with high parallel make(1) jobs with GCC
I have been pounding my head against the desk for longer than I care to
admit with this failure.
I see this with powerpc, powerpc64, and now ia64. I initially thought
it was specific to powerpc{,64}, but now realize ia64 is also affected.
This build was running with -j48 on a 48-core machine, when the
following caused build failure:
===
/usr/obj/ia64.ia64/usr/src/tmp/usr/bin/ld: cannot find -lm
--- libstdc++.so.6 ---
*** [libstdc++.so.6] Error code 1
make[4]: stopped in /usr/src/gnu/lib/libstdc++
A failure has been detected in another branch of the parallel make
===
It is unclear to me when exactly this started happening, but it seems at
least two weeks is a reasonable estimate.
I realize this is not an entirely large chunk of useful information
regarding the build failure, but I have determined it is entirely
reproducible. I have determined that the failure case seems to
disappear with make(1) jobs <= 10, at least for powerpc.
The last successful build for powerpc on head/ was April 8. But I am
having trouble tracking down what commits may (or may not) have
contributed to recent high-parallel build failures.
Glen
pgpSJRLp8hZGA.pgp
Description: PGP signature
Re: Build failures with high parallel make(1) jobs with GCC
On Mon, 2014-04-21 at 22:54 -0400, Glen Barber wrote:
> I have been pounding my head against the desk for longer than I care to
> admit with this failure.
>
> I see this with powerpc, powerpc64, and now ia64. I initially thought
> it was specific to powerpc{,64}, but now realize ia64 is also affected.
>
> This build was running with -j48 on a 48-core machine, when the
> following caused build failure:
>
> ===
>
> /usr/obj/ia64.ia64/usr/src/tmp/usr/bin/ld: cannot find -lm
> --- libstdc++.so.6 ---
> *** [libstdc++.so.6] Error code 1
>
> make[4]: stopped in /usr/src/gnu/lib/libstdc++
> A failure has been detected in another branch of the parallel make
>
> ===
>
> It is unclear to me when exactly this started happening, but it seems at
> least two weeks is a reasonable estimate.
>
> I realize this is not an entirely large chunk of useful information
> regarding the build failure, but I have determined it is entirely
> reproducible. I have determined that the failure case seems to
> disappear with make(1) jobs <= 10, at least for powerpc.
>
> The last successful build for powerpc on head/ was April 8. But I am
> having trouble tracking down what commits may (or may not) have
> contributed to recent high-parallel build failures.
>
> Glen
>
A couple weeks corresponds somewhat with the parallel subdir build
changes (it's about 3 weeks now). Try this patch I cooked up today for
$work, and in src/lib/Makefile add .WAIT (as if it were a directory
name) between ${SUBDIR_ORDERED} and the rest of the directories.
-- Ian
diff -r 67802e319fc6 share/mk/bsd.subdir.mk
--- a/share/mk/bsd.subdir.mk Sun Apr 20 21:01:07 2014 -0600
+++ b/share/mk/bsd.subdir.mk Mon Apr 21 06:59:37 2014 -0600
@@ -4,10 +4,10 @@
# The include file contains the default targets
# for building subdirectories.
#
-# For all of the directories listed in the variable SUBDIRS, the
+# For all of the directories listed in the variable SUBDIR, the
# specified directory will be visited and the target made. There is
# also a default target which allows the command "make subdir" where
-# subdir is any directory listed in the variable SUBDIRS.
+# subdir is any directory listed in the variable SUBDIR.
#
#
# +++ variables +++
@@ -42,7 +42,7 @@ distribute:
_SUBDIR: .USE
.if defined(SUBDIR) && !empty(SUBDIR) && !defined(NO_SUBDIR)
- @${_+_}for entry in ${SUBDIR}; do \
+ @${_+_}for entry in ${SUBDIR:N.WAIT}; do \
if test -d ${.CURDIR}/$${entry}.${MACHINE_ARCH}; then \
${ECHODIR} "===> ${DIRPRFX}$${entry}.${MACHINE_ARCH} (${.TARGET:realinstall=install})"; \
edir=$${entry}.${MACHINE_ARCH}; \
@@ -57,7 +57,7 @@ distribute:
done
.endif
-${SUBDIR}: .PHONY
+${SUBDIR:N.WAIT}: .PHONY
${_+_}@if test -d ${.TARGET}.${MACHINE_ARCH}; then \
cd ${.CURDIR}/${.TARGET}.${MACHINE_ARCH}; \
else \
@@ -65,13 +65,18 @@ distribute:
fi; \
${MAKE} all
+__wait=.WAIT
.for __target in all all-man checkdpadd clean cleandepend cleandir \
depend distribute lint maninstall manlint \
obj objlink realinstall regress tags \
${SUBDIR_TARGETS}
.ifdef SUBDIR_PARALLEL
+__subdir_targets=
.for __dir in ${SUBDIR}
-${__target}: ${__target}_subdir_${__dir}
+.if ${__wait} == ${__dir}
+__subdir_targets+= .WAIT
+.else
+__subdir_targets+= ${__target}_subdir_${__dir}
${__target}_subdir_${__dir}: .MAKE
@${_+_}set -e; \
if test -d ${.CURDIR}/${__dir}.${MACHINE_ARCH}; then \
@@ -85,7 +90,9 @@ distribute:
fi; \
${MAKE} ${__target:realinstall=install} \
DIRPRFX=${DIRPRFX}$$edir/
+.endif
.endfor
+${__target}: ${__subdir_targets}
.else
${__target}: _SUBDIR
.endif
___
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: Build failures with high parallel make(1) jobs with GCC
On Mon, Apr 21, 2014 at 09:09:42PM -0600, Ian Lepore wrote:
> > The last successful build for powerpc on head/ was April 8. But I am
> > having trouble tracking down what commits may (or may not) have
> > contributed to recent high-parallel build failures.
> >
>
> A couple weeks corresponds somewhat with the parallel subdir build
> changes (it's about 3 weeks now). Try this patch I cooked up today for
> $work, and in src/lib/Makefile add .WAIT (as if it were a directory
> name) between ${SUBDIR_ORDERED} and the rest of the directories.
>
The patch fails to apply cleanly, but as far as I can tell, it is due to
whitespace.
I'll hand-patch it, and report back.
Thanks.
Glen
pgp87jr3EfwFQ.pgp
Description: PGP signature
Re: Build failures with high parallel make(1) jobs with GCC
On Mon, Apr 21, 2014 at 11:21:24PM -0400, Glen Barber wrote:
> On Mon, Apr 21, 2014 at 09:09:42PM -0600, Ian Lepore wrote:
> > > The last successful build for powerpc on head/ was April 8. But I am
> > > having trouble tracking down what commits may (or may not) have
> > > contributed to recent high-parallel build failures.
> > >
> >
> > A couple weeks corresponds somewhat with the parallel subdir build
> > changes (it's about 3 weeks now). Try this patch I cooked up today for
> > $work, and in src/lib/Makefile add .WAIT (as if it were a directory
> > name) between ${SUBDIR_ORDERED} and the rest of the directories.
> >
>
> The patch fails to apply cleanly, but as far as I can tell, it is due to
> whitespace.
>
> I'll hand-patch it, and report back.
>
Nope, I'm getting conflicts on revisions as far back as r251749.
Glen
pgp_zIs2itvGG.pgp
Description: PGP signature
Re: Build failures with high parallel make(1) jobs with GCC
On Mon, 2014-04-21 at 23:26 -0400, Glen Barber wrote:
> On Mon, Apr 21, 2014 at 11:21:24PM -0400, Glen Barber wrote:
> > On Mon, Apr 21, 2014 at 09:09:42PM -0600, Ian Lepore wrote:
> > > > The last successful build for powerpc on head/ was April 8. But I am
> > > > having trouble tracking down what commits may (or may not) have
> > > > contributed to recent high-parallel build failures.
> > > >
> > >
> > > A couple weeks corresponds somewhat with the parallel subdir build
> > > changes (it's about 3 weeks now). Try this patch I cooked up today for
> > > $work, and in src/lib/Makefile add .WAIT (as if it were a directory
> > > name) between ${SUBDIR_ORDERED} and the rest of the directories.
> > >
> >
> > The patch fails to apply cleanly, but as far as I can tell, it is due to
> > whitespace.
> >
> > I'll hand-patch it, and report back.
> >
>
> Nope, I'm getting conflicts on revisions as far back as r251749.
>
> Glen
>
Doh! I completely forgot that's against 8.2 that we use at work. I'll
re-spin it for -current.
-- Ina
___
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: Build failures with high parallel make(1) jobs with GCC
On Mon, 2014-04-21 at 23:26 -0400, Glen Barber wrote:
> On Mon, Apr 21, 2014 at 11:21:24PM -0400, Glen Barber wrote:
> > On Mon, Apr 21, 2014 at 09:09:42PM -0600, Ian Lepore wrote:
> > > > The last successful build for powerpc on head/ was April 8. But I am
> > > > having trouble tracking down what commits may (or may not) have
> > > > contributed to recent high-parallel build failures.
> > > >
> > >
> > > A couple weeks corresponds somewhat with the parallel subdir build
> > > changes (it's about 3 weeks now). Try this patch I cooked up today for
> > > $work, and in src/lib/Makefile add .WAIT (as if it were a directory
> > > name) between ${SUBDIR_ORDERED} and the rest of the directories.
> > >
> >
> > The patch fails to apply cleanly, but as far as I can tell, it is due to
> > whitespace.
> >
> > I'll hand-patch it, and report back.
> >
>
> Nope, I'm getting conflicts on revisions as far back as r251749.
>
> Glen
>
This one should work better. The lib/Makefile is included this time.
-- Ian
Index: share/mk/bsd.subdir.mk
===
--- share/mk/bsd.subdir.mk (revision 264744)
+++ share/mk/bsd.subdir.mk (working copy)
@@ -45,7 +45,7 @@ distribute: .MAKE
_SUBDIR: .USE .MAKE
.if defined(SUBDIR) && !empty(SUBDIR) && !defined(NO_SUBDIR)
- @${_+_}set -e; for entry in ${SUBDIR}; do \
+ @${_+_}set -e; for entry in ${SUBDIR:N.WAIT}; do \
if test -d ${.CURDIR}/$${entry}.${MACHINE_ARCH}; then \
${ECHODIR} "===> ${DIRPRFX}$${entry}.${MACHINE_ARCH} (${.TARGET:realinstall=install})"; \
edir=$${entry}.${MACHINE_ARCH}; \
@@ -60,7 +60,7 @@ _SUBDIR: .USE .MAKE
done
.endif
-${SUBDIR}: .PHONY .MAKE
+${SUBDIR:N.WAIT}: .PHONY .MAKE
${_+_}@if test -d ${.TARGET}.${MACHINE_ARCH}; then \
cd ${.CURDIR}/${.TARGET}.${MACHINE_ARCH}; \
else \
@@ -68,12 +68,18 @@ _SUBDIR: .USE .MAKE
fi; \
${MAKE} all
+# Work around parsing of .if nested in .for by putting .WAIT string into a var.
+__wait= .WAIT
.for __target in all all-man checkdpadd clean cleandepend cleandir \
cleanilinks depend distribute lint maninstall manlint obj objlink \
realinstall regress tags ${SUBDIR_TARGETS}
.ifdef SUBDIR_PARALLEL
+__subdir_targets=
.for __dir in ${SUBDIR}
-${__target}: ${__target}_subdir_${__dir}
+.if ${__wait} == ${__dir}
+__subdir_targets+= .WAIT
+.else
+__subdir_targets+= ${__target}_subdir_${__dir}
${__target}_subdir_${__dir}: .MAKE
@${_+_}set -e; \
if test -d ${.CURDIR}/${__dir}.${MACHINE_ARCH}; then \
@@ -87,7 +93,9 @@ ${__target}_subdir_${__dir}: .MAKE
fi; \
${MAKE} ${__target:realinstall=install} \
DIRPRFX=${DIRPRFX}$$edir/
+.endif
.endfor
+${__target}: ${__subdir_targets}
.else
${__target}: _SUBDIR
.endif
Index: lib/Makefile
===
--- lib/Makefile (revision 264744)
+++ lib/Makefile (working copy)
@@ -62,6 +62,7 @@ SUBDIR_ORDERED+= libcom_err
.endif
SUBDIR= ${SUBDIR_ORDERED} \
+ .WAIT \
libalias \
libarchive \
${_libatm} \
___
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: Build failures with high parallel make(1) jobs with GCC
On Mon, Apr 21, 2014 at 10:05:57PM -0600, Ian Lepore wrote:
> On Mon, 2014-04-21 at 23:26 -0400, Glen Barber wrote:
> > On Mon, Apr 21, 2014 at 11:21:24PM -0400, Glen Barber wrote:
> > > On Mon, Apr 21, 2014 at 09:09:42PM -0600, Ian Lepore wrote:
> > > > > The last successful build for powerpc on head/ was April 8. But I am
> > > > > having trouble tracking down what commits may (or may not) have
> > > > > contributed to recent high-parallel build failures.
> > > > >
> > > >
> > > > A couple weeks corresponds somewhat with the parallel subdir build
> > > > changes (it's about 3 weeks now). Try this patch I cooked up today for
> > > > $work, and in src/lib/Makefile add .WAIT (as if it were a directory
> > > > name) between ${SUBDIR_ORDERED} and the rest of the directories.
> > > >
> > >
> > > The patch fails to apply cleanly, but as far as I can tell, it is due to
> > > whitespace.
> > >
> > > I'll hand-patch it, and report back.
> > >
> >
> > Nope, I'm getting conflicts on revisions as far back as r251749.
> >
> > Glen
> >
>
> This one should work better. The lib/Makefile is included this time.
>
This patch applies fine.
It seems to already have an effect, but I won't go so far to say it
works until I see the 'World build completed: ' message.
I'll follow up tomorrow once build is done.
Thanks!
Glen
pgpLJk4hZ47Ik.pgp
Description: PGP signature
