Re: [CFT] WITH_META_MODE: Working incremental build

On Fri, May 27, 2016 at 05:16:25PM -0700, Bryan Drewery wrote: > The way that "meta mode" works is to enable the bmake "meta mode" > feature that tracks the build command for each target and uses the > filemon(4) [1] module to track all files read/written/executed for > building target. If any of

FreeBSD_HEAD_i386 - Build #3231 - Fixed

update /etc/fstab or geom labels. Reviewed by:ken, mav MFC after: Never Sponsored by: Spectra Logic Corp Differential Revision: https://reviews.freebsd.org/D6516 300879 by jkim: Merge ACPICA 20160527. Relnotes: yes 300878 by ian: Fix erronious mixed use of tx/rx

Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)

On 2016-May-27, at 7:04 PM, Mark Millard wrote: > FYI. . . > > I expect that building gcc49 with: > > + --with-local-prefix=/usr \ > > will help with system build activities via gcc49/g++49 by avoiding > /usr/local/include interfering. > > But I also expect that various port

Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)

FYI. . . I expect that building gcc49 with: + --with-local-prefix=/usr \ will help with system build activities via gcc49/g++49 by avoiding /usr/local/include interfering. But I also expect that various port builds based on that same gcc49/g++49 will have problems from not

Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)

On 5/27/2016 5:15 PM, Mark Millard wrote: > + --with-local-prefix=/usr/include \ > > looks wrong to me. The default is not /usr/local/include but just /usr/local > . Quoting https://gcc.gnu.org/install/configure.html : > > --with-local-prefix=dirname > Specify the installation

[CFT] WITH_META_MODE: Working incremental build

Buildworld/Buildkernel now supports a working incremental build. Using -DNO_CLEAN is not needed as it is the default with it (there is no -DCLEAN for it). The normal -DNO_CLEAN feature is broken and risky since it does not track a ton of the dependencies in the build such as the compiler, other

Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)

On 2016-May-27, at 4:48 PM, Bryan Drewery wrote: > On 3/31/2016 8:33 PM, Mark Millard wrote: >> I appears that C++ needs its own override for where to find C++ header >> before looking in the gcc49 specific places. > > Yes, the hacks for that are builtin already. Passing C_INCLUDE_PATH and >

Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)

On 3/31/2016 8:33 PM, Mark Millard wrote: > I appears that C++ needs its own override for where to find C++ header before > looking in the gcc49 specific places. Yes, the hacks for that are builtin already. Passing C_INCLUDE_PATH and others may break it. > These sorts of odd, hard to avoid

Build failed in Jenkins: FreeBSD_HEAD #307

See -- [...truncated 318477 lines...] [192.168.10.2] out: sys/posixshm/posixshm_test:open_after_link -> passed [0.069s] [192.168.10.2] out: sys/posixshm/posixshm_test:open_anon -> passed [0.055s]

Re: [PATCH] microoptimize locking primitives by avoiding unnecessary atomic ops

On Friday, May 27, 2016 09:17:01 PM Mateusz Guzik wrote: > Hello there, > > quite some time ago I posted a trivial patch to locking primitives. What > they do is the inline part tries an atomic op and if that fails the > actual function is called, which immediately tries the same op. > > The

FreeBSD_HEAD_i386 - Build #3230 - Failure

FreeBSD_HEAD_i386 - Build #3230 - Failure: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/3230/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/3230/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/3230/console Change summaries:

Re: [PATCH] microoptimize locking primitives by avoiding unnecessary atomic ops

On 05/27/16 02:17 PM, Mateusz Guzik wrote: > Hello there, > > quite some time ago I posted a trivial patch to locking primitives. What > they do is the inline part tries an atomic op and if that fails the > actual function is called, which immediately tries the same op. > > The obvious

Re: cannot represent machine `mips:amd64'

On Fri, May 27, 2016 at 07:56:57PM +, Glen Barber wrote: > On Fri, May 27, 2016 at 01:48:25PM -0600, Alan Somers wrote: > > Starting today, I get this error for several mips targets whenever I > > do "make universe". Does anybody know what might be causing it? I > > see it for mips.mips64,

Re: cannot represent machine `mips:amd64'

On Fri, May 27, 2016 at 1:56 PM, Glen Barber wrote: > On Fri, May 27, 2016 at 01:48:25PM -0600, Alan Somers wrote: >> Starting today, I get this error for several mips targets whenever I >> do "make universe". Does anybody know what might be causing it? I >> see it for

Re: cannot represent machine `mips:amd64'

On Fri, May 27, 2016 at 01:48:25PM -0600, Alan Somers wrote: > Starting today, I get this error for several mips targets whenever I > do "make universe". Does anybody know what might be causing it? I > see it for mips.mips64, mips.mipsn32, and mips.mips64el . > >

cannot represent machine `mips:amd64'

Starting today, I get this error for several mips targets whenever I do "make universe". Does anybody know what might be causing it? I see it for mips.mips64, mips.mipsn32, and mips.mips64el . -- >>> stage 4.2: building libraries

[PATCH] microoptimize locking primitives by avoiding unnecessary atomic ops

Hello there, quite some time ago I posted a trivial patch to locking primitives. What they do is the inline part tries an atomic op and if that fails the actual function is called, which immediately tries the same op. The obvious optimisation checks for the availability of the lock first. There

Build failed in Jenkins: FreeBSD_HEAD #306

ct -> passed [0.026s] [192.168.10.2] out: sys/vfs/trailing_slash:main -> passed [0.065s] [192.168.10.2] out: sys/vm/mmap_test:mmap__bad_arguments -> passed [0.029s] [192.168.10.2] out: sys/vm/mmap_test:mmap__dev_zero_private -> passed [0.024s] [192.168.10.2] out: sys/vm/mmap_t

Re: EARLY_AP_STARTUP hangs during boot

On Friday, May 27, 2016 09:50:05 AM Gary Jennejohn wrote: > On Thu, 26 May 2016 16:54:35 -0700 > John Baldwin wrote: > > > On Tuesday, May 17, 2016 06:47:41 PM Gary Jennejohn wrote: > > > On Mon, 16 May 2016 10:54:19 -0700 > > > John Baldwin wrote: > > > >

FreeBSD_HEAD_amd64_gcc - Build #1266 - Failure

FreeBSD_HEAD_amd64_gcc - Build #1266 - Failure: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1266/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1266/changes Full build log:

Re: exports(5) no longer allows multiple paths per line?

> On May 26, 2016, at 23:28, Ed Schouten wrote: > > Hi there, > > 2016-05-27 4:12 GMT+02:00 Ngie Cooper : >>It seems like the following /etc/exports should work, but for some >> odd reason specifying both paths on a single line doesn't work (I >> swore

Re: EARLY_AP_STARTUP hangs during boot

On Thu, 26 May 2016 16:54:35 -0700 John Baldwin wrote: > On Tuesday, May 17, 2016 06:47:41 PM Gary Jennejohn wrote: > > On Mon, 16 May 2016 10:54:19 -0700 > > John Baldwin wrote: > > > > > On Monday, May 16, 2016 12:22:42 PM Gary Jennejohn wrote: > > > >

Re: exports(5) no longer allows multiple paths per line?

Hi there, 2016-05-27 4:12 GMT+02:00 Ngie Cooper : > It seems like the following /etc/exports should work, but for some > odd reason specifying both paths on a single line doesn't work (I > swore it was working on a kernel/userland built in the past month, > i.e.